Multi-CPU distributed negotiation control method and device for aerospace flight control and rocket

Abstract

The embodiment of the invention provides a multi-CPU distributed negotiation control method and device for space flight control, and a rocket, and the method comprises the steps: carrying out the negotiation of any available CPU node with all CPU nodes in each control period of the flight control of a space carrier rocket, so as to determine the CPU node as a decision maker of the control period, if the negotiator obtains negotiation agreement response messages of which the quantity is not less than the preset quantity, confirming that the negotiator is used as a decision maker of the control period; the responders respectively carry out resolving to obtain respective corresponding initial flight control resolving results, and the decision maker sends a result request to all responders to inquire the initial flight control resolving results; the responder sends an initial flight control calculation result corresponding to the responder to the decision maker passing verification; and the decision maker determines a final flight control calculation result according to the received initial flight control calculation result and a preset rule. When any CPU node breaks down, the final flight control settlement result can still be obtained, and redundancy control is achieved.

Description

Technical Field

[0001] The present invention relates to the field of aerospace, and in particular to a multi-CPU distributed negotiation control method and device for aerospace flight control, and a rocket. Background Art

[0002] The flight control computer on a traditional space launch vehicle has only one core CPU control unit. With the advancement of computer technology, the use of multi-mode flight control computing nodes (CPU nodes) on the flight control system of a space launch vehicle to independently perform flight control settlement and parallel computing is about to become the mainstream technology.

[0003] In the process of implementing the present invention, the applicant discovered that the prior art has at least the following problems:

[0004] Although multi-mode flight control computing nodes are currently being deployed in various space launch vehicles, they still rely on the assistance of other hardware and systems on the space launch vehicles. They have not "formed effective control methods at the software and algorithm level to enable multi-mode flight control to interact and compare to form decisions, so that redundant control can still be achieved in the event of a failure." Summary of the Invention

[0005] The embodiments of the present invention provide a multi-CPU distributed negotiation control method, device and rocket for aerospace flight control, which can solve the technical problem that "although multi-mode flight control computing nodes are currently being deployed in various aerospace launch vehicles, they still rely on the assistance of other hardware and systems on the aerospace launch vehicles, and cannot form an effective control method at the software and algorithm level to enable multi-mode flight control to interact and compare to form decisions so that redundant control can still be achieved in the event of a failure."

[0006] To achieve the above objectives, in a first aspect, an embodiment of the present invention provides a multi-CPU distributed negotiation control method for a space launch vehicle flight control, comprising:

[0007] Step 1: During each control cycle of a space launch vehicle's flight control, before calculating various sensor data and / or rocket body equipment operating status information, any available CPU node acts as a negotiator to negotiate with all CPU nodes via a high-speed bus to determine whether it is the decision maker for this control cycle. All CPU nodes determine whether to agree with the negotiator as the decision maker for this control cycle based on preset rules. If the negotiator receives no less than a preset number of negotiation agreement response messages, it confirms that it is the decision maker for this control cycle. The number of CPU nodes is an odd number.

[0008] Step 2: Each responder performs calculations based on various sensor data and / or rocket equipment operating status information collected during this control cycle to obtain their respective initial flight control calculation results, where the responders are all CPU nodes;

[0009] Step 3: The decision maker sends a result request to all responders to inquire about the initial flight control solution result;

[0010] Step 4: The responder sends the initial flight control solution corresponding to the responder to the verified decision maker;

[0011] Step 5: The decision maker determines the final flight control solution result according to the received initial flight control solution result according to preset rules, and sends the final flight control solution result to the real-time bus. The final flight control solution result is used to control the operation of the space launch vehicle.

[0012] In a second aspect, an embodiment of the present invention provides a multi-CPU distributed negotiation control device for aerospace flight control, comprising:

[0013] A negotiation module is used for each control cycle of a space launch vehicle's flight control. Before calculating various sensor data and / or rocket body equipment operating status information, any available CPU node acts as a negotiator to negotiate with all CPU nodes via a high-speed bus to determine whether it is the decision maker for this control cycle. All CPU nodes determine whether to agree with the negotiator as the decision maker for this control cycle based on preset rules. If the negotiator receives no less than a preset number of negotiation agreement response messages, it confirms that it is the decision maker for this control cycle. The number of CPU nodes is an odd number.

[0014] Responders, each of which performs calculations based on various sensor data and / or rocket equipment operating status information collected during this control cycle to obtain its own corresponding initial flight control solution results, wherein the responders are all CPU nodes;

[0015] The decision maker sends a result request to all responders to inquire about the initial flight control solution result;

[0016] The responder sends the initial flight control solution result corresponding to the responder to the verified decision maker;

[0017] The decision maker determines a final flight control solution result according to preset rules based on the received initial flight control solution result, and sends the final flight control solution result to a real-time bus. The final flight control solution result is used to control the operation of the space launch vehicle.

[0018] In a third aspect, an embodiment of the present invention provides a space launch vehicle, comprising the aforementioned multi-CPU distributed negotiation control device for space flight control.

[0019] The above technical solution has the following beneficial effects:

[0020] Each CPU node, acting as a computing and communication node, plays the roles of negotiator, decision-maker, and responder. Each CPU node can play multiple roles simultaneously. Initially, the CPU node enters the negotiation phase, acting as both responder and negotiator. During the control phase, the CPU node acts as both decision-maker and responder. CPU nodes without decision-making power are merely responders, while decision-makers also serve as responders.

[0021] In an embodiment of the present invention, multiple CPUs negotiate within each control cycle to determine a CPU node as the decision maker, which issues comprehensive control instructions (including multiple timing control comprehensive instructions) for that control cycle (e.g., each control cycle is 10ms). That is, each control cycle requires multiple CPUs to negotiate to determine the decision maker for each round, who ultimately issues the control instructions for that round. This allows for synchronized and coordinated decision-making among multiple CPUs, ensuring that the initial solution results of multiple (odd number of) CPUs are ultimately unified into a final flight control settlement result, which is sent to the actuator as the control result for controlling the operation of the space launch vehicle.

[0022] The embodiment of the present invention does not need to rely on the assistance of other hardware and systems on the rocket to complete, and can form an effective control method at its own software and algorithm level, so that multi-mode flight control can interact and compare to form a control result. When one of the flight control computing nodes fails, the final flight control settlement result can still be obtained, thereby realizing redundant control. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0024] Figure 1 This is a flow chart of a multi-CPU distributed negotiation control method for a space launch vehicle flight control system according to an embodiment of the present invention;

[0025] Figure 2 This is a structural diagram of a multi-CPU distributed negotiation control device for a space launch vehicle flight control system according to an embodiment of the present invention;

[0026] Figure 3is a schematic diagram of a distributed negotiation control method according to an embodiment of the present invention;

[0027] Figure 4 is a description of the roles and message types of an embodiment of the present invention;

[0028] Figure 5 This is a schematic diagram of a typical multi-CPU distributed negotiation process according to an embodiment of the present invention;

[0029] Figure 6 This is a schematic diagram of a process of reaching consensus through multiple negotiations according to an embodiment of the present invention;

[0030] Figure 7 This is a schematic diagram of a process in which consensus is finally reached after packet loss in the middle of an embodiment of the present invention. DETAILED DESCRIPTION

[0031] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. 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 making creative efforts are within the scope of protection of the present invention.

[0032] like Figure 1 As shown, in combination with an embodiment of the present invention, a multi-CPU distributed negotiation control method for a space launch vehicle flight control is provided, comprising:

[0033] Step 1: During each control cycle of a space launch vehicle's flight control, before calculating various sensor data and / or rocket body equipment operating status information, any available CPU node acts as a negotiator to negotiate with all CPU nodes via a high-speed bus to determine whether it is the decision maker for this control cycle. All CPU nodes determine whether to agree with the negotiator as the decision maker for this control cycle based on preset rules. If the negotiator receives no less than a preset number of negotiation agreement response messages, it confirms that it is the decision maker for this control cycle. The number of CPU nodes is an odd number, at least three.

[0034] Step 2: Each responder performs calculations based on various sensor data and / or rocket equipment operating status information collected during this control cycle to obtain their respective initial flight control calculation results, where the responders are all CPU nodes;

[0035] Step 3: The decision maker sends a result request to all responders to inquire about the initial flight control solution result;

[0036] Step 4: The responder sends the initial flight control solution corresponding to the responder to the verified decision maker;

[0037] Step 5: The decision maker determines the final flight control solution result according to the received initial flight control solution result according to preset rules, and sends the final flight control solution result to the real-time bus. The final flight control solution result is used to control the operation of the space launch vehicle.

[0038] The multi-CPU flight control system of a space launch vehicle deploys a real-time bus and a high-speed bus. The real-time bus has the following characteristics: (1) a strong real-time control bus, (2) a master-slave structure with one master device and multiple slave devices, (3) devices monitoring bus messages, and (4) a low-speed (e.g., 1Mb / s) reliable transmission bus. The high-speed bus has the following characteristics: (1) a transmission rate of 100Mb / s or higher, (2) non-real-time performance, (3) a collision detection and retransmission mechanism that does not guarantee reliable transmission, and (4) support for simultaneous transmission and reception by multiple terminals.

[0039] Among them, the flight control system of a space launch vehicle consists of a perception system, a computing and decision-making system, an actuator, a telemetry system and a real-time control system. The flight control computer belongs to the computing and decision-making system. Buses such as 1553B and CAN are relatively typical master-slave real-time buses used in aerospace systems. They are used to connect the perception system and the real-time control system on a space launch vehicle. Ethernet is a relatively typical high-speed bus used in aerospace control systems. It is used to connect the real-time control system and the telemetry system for non-real-time communication. The onboard control system connected by the two buses is as follows: Figure 3 As shown in the figure, for the sake of simplicity, the examples are described using a system with three CPUs as a typical case.

[0040] In a computing decision-making system, each flight control computing node is a module, and each flight control computing node has a CPU, so one CPU is also called one module. A multi-CPU distributed negotiation control method for aerospace flight control systems according to an embodiment of the present invention supports multi-mode systems with three or more modules. The flight control computer of a space launch vehicle performs real-time control of the equipment on the space launch vehicle at a fixed cycle (taking a 10ms operating cycle as an example). During each cycle, it collects sensor data and operating status from each module on the rocket body, performs calculations according to flight mission requirements, issues corresponding execution instructions to each controlled module within a 10ms cycle, and then waits for the next 10ms clock pulse interrupt to perform calculations and control for the next cycle.

[0041] Each CPU node, acting as a computing and communication node, plays the roles of negotiator, decision-maker, and responder. Each CPU node can play multiple roles simultaneously. Initially, the CPU node enters the negotiation phase, acting as both responder and negotiator. During the control phase, the CPU node acts as both decision-maker and responder. CPU nodes without decision-making power are merely responders, while decision-makers also serve as responders.

[0042] In an embodiment of the present invention, multiple CPUs negotiate within each control cycle to determine a CPU node as the decision maker, which issues comprehensive control instructions (including multiple timing control comprehensive instructions) for that control cycle (e.g., each control cycle is 10ms). That is, each control cycle requires multiple CPUs to negotiate to determine the decision maker for each round, who ultimately issues the control instructions for that round. This allows for synchronized and coordinated decision-making among multiple CPUs, ensuring that the initial solution results of multiple (odd number of) CPUs are ultimately unified into a final flight control settlement result, which is sent to the actuator as the control result for controlling the operation of the space launch vehicle.

[0043] Without relying on the assistance of other hardware and systems on the rocket, an effective control method can be formed at the software and algorithm level, allowing multi-mode flight control to interact and compare to form control results. Then, when one of the flight control computing nodes fails, the final flight control settlement result can still be obtained, thus achieving redundant control.

[0044] Preferably, the multi-CPU distributed negotiation control method for aerospace flight control further includes:

[0045] Step 6: All CPU nodes collect various sensor data and / or operating status information of the space launch vehicle from the real-time bus, and use them to perform flight control calculations on each CPU node; wherein step 6 is performed in parallel with step 1;

[0046] Step 7: After the negotiator confirms that it is the decision maker of this control cycle, it notifies all CPU nodes on the real-time bus that it is the decision maker of this control cycle, so that the respondent can obtain information about who is the decision maker.

[0047] Preferably, the multi-CPU distributed negotiation control method for aerospace flight control further includes:

[0048] Step 8: Set a unique digital number for each CPU node, wherein step 8 is performed before step 6;

[0049] Among them, step 1 also includes: in each control cycle, each CPU node forms its own self-incrementing number in the current control cycle based on the unique digital number and the self-incrementing number of the previous control cycle, wherein the initial value of the self-incrementing number of each CPU node is its own unique digital number.

[0050] Specifically, K is used to represent the total number of CPU nodes, and J is a unique digital number for each CPU node. The recommended value of J is 0 to (K-1). Assuming K is 3, the J values of the three CPU nodes are 0, 1, and 2 respectively. For each CPU node, each CPU node uses a unidirectionally increasing, global, non-unique digital number in each control cycle, and the symbol N is used to represent the digital number. It is recommended to use a 64-bit unsigned integer to represent N, which can ensure that N will not overflow during the life cycle of the rocket flight control (that is, there will be no duplication errors). If the flight control of a space launch vehicle uses a control cycle of 10ms (also called a solution cycle), each CPU node must calculate its own N at the beginning of each control cycle, that is, before sending a negotiation request at the beginning of each 10ms, each CPU node performs a self-increment operation to obtain its own N: symbol express Round up; assuming that N increments once per solution cycle, it requires 2.13504*10 12 / K day is about 5.85*10 9 Overflow will occur only after / K years.

[0051] Preferably, in step 1, all the CPU nodes respectively determine whether to agree with the negotiator as the decision maker of this control cycle according to preset rules, which specifically includes:

[0052] Any available CPU node acts as a negotiator and sends a negotiation request to all CPU nodes via the high-speed bus. The negotiation request contains the negotiation field and the negotiator's auto-increment number.

[0053] After receiving the negotiation request, each CPU node determines whether the self-incrementing number of the negotiator in the negotiation request is greater than the self-incrementing number of the decision maker agreed by the CPU node in the previous control cycle;

[0054] If it is greater than, a negotiation approval response message is sent to the negotiator, agreeing that the negotiator is the decision maker, and the CPU node that sends the negotiation approval response message records the self-increment number of the decision maker that it agrees with; otherwise, a negotiation rejection response message is sent to the negotiator, rejecting the negotiator as the decision maker;

[0055] If the number of negotiation agreement response messages obtained by the negotiator is not less than half of the number of CPU nodes, the negotiator determines itself as the decision maker of this control cycle.

[0056] Specifically, the communication message types between different roles are described as follows:

[0057] Negotiation request: (negotiation.N); where N is the negotiator, indicating that the negotiation request is issued by N and is used to negotiate with N as the decision maker;

[0058] Negotiation response: (agree.N); indicates that another CPU node agrees that N is the decision maker;

[0059] Result request: (request.N); indicates that N issues a result request;

[0060] Result response: (result.N, calculation result); indicates that the calculation result has been sent to N;

[0061] Reject response: (reject.N); indicates refusal to send the initial flight control solution result to N.

[0062] Each CPU node also needs to maintain an agreed number N value. At the beginning, that is, before entering the first control cycle, each CPU node needs to set an initial value of the self-incrementing number of the decision maker of the response request that has been agreed. The initial value represents the decision maker of the response request that it has agreed to. The initial value is set to the CPU node's own unique digital number, that is, agreed. N = J, where J is the unique number of the CPU node.

[0063] To determine the decision-maker for the current solution cycle, each CPU node has the right to send a negotiation request to all responders. The request content is (negotiate.N), where the negotiation field contains the word "negotiate" and the negotiator's self-incrementing number is N. Negotiate.N is calculated using the self-incrementing formula (negotiate.N = agreed.N + J + 1). The request is made to become the decision-maker for the current solution cycle. After receiving the negotiation request, the responder can only send a negotiation approval reply message to the negotiator, agreeing to assign the negotiator the decision-maker role, only if Negotiate.N > its previous agreed number (the number it previously agreed to). The negotiation approval reply message contains (agree.N). Otherwise, a negotiation rejection reply message is sent, containing (reject.N). This ensures the legitimacy of each decision round and can also determine the decision-maker even if individual CPU nodes fail, ensuring the normal operation of flight control solutions.

[0064] After the responder agrees to the negotiator becoming the decision maker, the responder needs to record the agreed (negotiation.N), assign a value (agreement.N = negotiation.N), and no longer accept new negotiation requests (negotiation.N ≤ agreed.N). At the same time, the responder cannot accept result requests (request.N < agreed.N). Each reply message of the responder contains the response number (response.N = agreed.N) to ensure accuracy of subsequent work.

[0065] And because the number of CPU nodes is an odd number, combined with the judgment principle of determining negotiation, if When (round down) CPU nodes have abnormalities, this negotiation control method can still be executed normally.

[0066] Preferably, in step 1, all the CPU nodes respectively determine whether to agree with the negotiator as the decision maker of this control cycle according to preset rules, which specifically includes:

[0067] If the number of negotiation agreement response messages received by the negotiator is less than half of the number of CPU nodes, then after waiting for the floating time interval, a new negotiation request is sent to all CPU nodes via the high-speed bus.

[0068] If the negotiator has not received the consent of more than half of the responders and has not sent a negotiation response of consent, it can wait for J*0.1+r (r is a random floating point number between 0 and 0.1) milliseconds and then send a negotiation request again, where the self-increment operation is used to obtain its own N: symbol express This random waiting process, rounded up, can resolve livelock during negotiation. Livelock occurs when two CPU nodes initiate simultaneous requests, making it impossible to determine which is the more appropriate decision-maker. The two CPU nodes must wait for the next round of negotiation, using a floating interval (J*0.1+r (r is a random floating point number between 0 and 0.1) milliseconds) associated with their unique numbers. If the waiting time is the same, the two CPU nodes will wait indefinitely, resulting in livelock.

[0069] Preferably, step 3 specifically includes:

[0070] The decision maker sends a result request to all responders to inquire about the initial flight control solution result, and the keywords of the result request include: a result field and a self-incrementing number of the decision maker;

[0071] Step 4 specifically includes:

[0072] If the self-incrementing number of the decision maker in the result request received by the respondent is greater than or equal to the self-incrementing number of the decision maker agreed by the respondent in this control cycle, the initial flight control solution result obtained will be sent to the decision maker corresponding to the result request in the form of a result sending response message; otherwise, a result rejection response message will be sent to the decision maker corresponding to the result request.

[0073] During the decision-making phase, the decision-maker sends a result request to all responders, who then respond or refuse to respond. The responder that receives the result request responds to the decision-maker that has been verified by the numbering judgment rule: If result request.N ≥ agreed.N, the responder uses its own initial flight control solution result as the response content: (result.N, calculation result) to form a result send response message and sends it to the decision-maker; otherwise, it sends a result rejection response message to the decision-maker. Based on the characteristics of the self-incrementing number formation, the self-incrementing number of the decision-maker that the responder agrees with is used to control whether the initial flight control solution result is sent to the decision-maker that sent the result request, thereby sending the flight control solution result to as few decision-makers as possible, ensuring that only a unique decision-maker can form a flight control solution result.

[0074] Preferably, step 3 further includes:

[0075] If there are two or more decision makers determined in step 1, each decision maker sends a result request to all responders to inquire about the initial flight control solution result;

[0076] Step 4 specifically includes:

[0077] When there are two or more result requests, if the self-incrementing number of the decision maker in the previous result request received by the responder is greater than or equal to the self-incrementing number of the decision maker agreed by the responder in the current control cycle, the initial flight control solution result is formed into a result sending reply message and sent to the decision maker corresponding to the previous result request; otherwise, a result rejection reply message is sent to the decision maker in the previous result request;

[0078] If the self-incrementing number of the decision maker in the subsequent result request received by the respondent is smaller than the self-incrementing number of the decision maker in the previous result request, a result rejection response message is sent to the decision maker corresponding to the subsequent result request;

[0079] If the self-incrementing number of the decision maker in the subsequent result request received by the respondent is greater than the self-incrementing number of the decision maker in the previous result request, and the self-incrementing number of the decision maker in the subsequent result request is the self-incrementing number of the decision maker agreed by the respondent, then a result sending reply message is sent to the decision maker corresponding to the subsequent result request, and the self-incrementing number of the negotiator agreed by the respondent is updated to the self-incrementing number of the decision maker in the subsequent result request;

[0080] If the self-incrementing number of the decision maker in the subsequent result request received by the respondent is greater than the self-incrementing number of the decision maker in the previous result request, and the self-incrementing number of the decision maker in the subsequent result request is not the self-incrementing number of the decision maker agreed by the respondent, then a result rejection response message is sent to the decision maker corresponding to the subsequent result request;

[0081] The respondent receives the previous result request earlier than the respondent receives the next result request.

[0082] If high-speed bus data message loss occurs during the negotiation control process, the distributed negotiation control device can still be controlled to operate normally through the negotiation and decision-making process; even if multiple decision makers appear in the negotiation stage, the self-incrementing number of the decision maker agreed by oneself is used to control whether the initial flight control solution result is sent to the decision maker who sent the result request according to the formation characteristics of the self-incrementing number, so that the flight control solution result is sent to as few decision makers as possible, and it is still possible to achieve the preset process in the decision stage to let the truly appropriate decision maker make the decision, and ensure that only a unique decision maker can form the flight control solution result.

[0083] Preferably, step 5 specifically includes:

[0084] If the initial flight control solution results received by the decision maker from the respondent are different, the settlement result is selected according to the rule of minority obeys majority, and when there are more than two different initial flight control settlement results, the two most recent initial flight control solution results are selected, and the arithmetic average of the two closest flight control settlement results is used as the final flight control solution result.

[0085] If the decision maker receives the initial flight control solution sent by more than half of the responders, half means Express The decision maker can summarize the received initial flight control solution results, or if no more than half of the responders have sent initial flight control solution results, collect as many initial flight control solution results as possible, and make a comprehensive judgment to determine the final flight control solution result within this control cycle.

[0086] In summary, if Figure 4 As shown, a CPU node can have one or more of three roles:

[0087] Negotiator: Each CPU node is a negotiator and can send negotiation requests to all responders. After receiving valid responses from more than half of them, it confirms itself as the decision maker of this control cycle.

[0088] Decision maker: Before starting its own flight control solution, it sends a result request to other responders. After receiving replies from more than half of the responders, it integrates all the response results and sends a control command through the real-time bus.

[0089] Responder: Maintains its own number N and agreed.N, accepts requests from negotiators and decision makers, and gives responses based on the logical requirements below. The response content can be a negotiation response, result response, or rejection response.

[0090] like Figure 3 As shown, this is a multi-CPU distributed negotiation control method, and each control cycle needs to complete Figure 3 The calculation and control process of the six steps.

[0091] 1. Data acquisition: The CPU node collects various sensor data and rocket equipment operating status information on the space launch vehicle from the real-time bus;

[0092] 2. During the negotiation phase, CPU nodes negotiate with each other via the high-speed bus to determine the decision maker for this control cycle.

[0093] 3. The CPU node that obtains the decision maker role announces the decision maker to all CPU nodes on the real-time bus;

[0094] 4. Each CPU node enters the flight control solution phase. Each CPU node performs calculations. Under normal circumstances, the calculation results should be the same;

[0095] 5. During the decision-making phase, the decision maker asks each CPU node (i.e., responder) for the initial flight control solution result. The responder sends the final flight control solution result after completing this round of calculations.

[0096] 6. During the decision-making stage, after the decision-maker obtains the initial flight control solution results of each respondent, it can follow the rule of minority obeys majority; when the initial flight control solution results of the CPU nodes are different, the arithmetic average of the two closest initial flight control solution results is used, and the result is sent to the real-time bus to control the operation of the space launch vehicle (i.e., control execution).

[0097] Example 1 is a typical decision-making process of multi-CPU distributed negotiation control in aerospace flight control. Figure 5 As shown, the three CPU nodes participating in the distributed negotiation control are labeled CPU0 (J=0), CPU1 (J=1), and CPU2 (J=2). Initially, they can set Agreed.N=J. During the negotiation phase, CPU2 sends a negotiation request (Negotiation.N=6) to itself, CPU1, and CPU0. CPU0, CPU1, and CPU2 agree to the request and set their own (Agreed.N) to 6, completing the negotiation phase. CPU2 then notifies all nodes on the real-time bus that it has become the decision maker.

[0098] During the decision-making phase, CPU2 is the decision maker and sends a result request (result request.N=6) to all responders. Since all responders' (agree.N=6) meet the condition (result request.N≥agree.N), all responders send their calculation results, i.e., the initial flight control solution results, to the decision maker in the form of (result.N=6, calculation result). After receiving more than half of the calculation results, the decision maker, CPU2, makes a comprehensive assessment and sends the control command to the real-time bus, completing one cycle of the flight control process.

[0099] Example 2: The negotiation process is completed after the negotiation process is rejected, such as Figure 6 As shown in the figure, when entering the negotiation phase, suppose that due to factors such as high-speed network bus packet loss, the three CPU nodes have already had inconsistent Agreed.N values during early operation. When CPU2 sends negotiation requests to CPU1 and CPU0, they are rejected because the condition Negotiated.N ≥ Agreed.N is not met. CPU1 then sends negotiation requests to CPU0 and CPU2. Because Negotiated.N = 11, which is greater than the Agreed.N values of CPU0 and CPU2, CPU1 receives an agreement, confirming that CPU1 has become the decision maker.

[0100] Example 3: The process of multiple negotiations and finally reaching a consensus result due to high-speed bus data packet loss, such as Figure 7 As shown in (a), at the beginning of the negotiation, it is assumed that the three CPU nodes have already formed an agreement on N in the early operation process, and there is inconsistency. CPU0 sends a negotiation request to CPU1 and CPU2. Since it receives a response from CPU1 and combines its own response, although it does not receive a negotiation response from CPU2 due to network packet loss, because the number of responders is 2, which exceeds half, CPU0 believes that it has become the decision maker. Figure 7 As shown in (b), at this time, CPU2 believes that there is no legitimate decision maker, so it also sends a negotiation request to CPU0 and CPU1. Assume that network packet loss occurs again at this time, CPU2 does not receive a response from CPU0, but the responses from both CPU1 and CPU2 have determined that CPU2 can become the decision maker, and CPU1 has agreed at this time. N = 6.

[0101] After entering the decision phase, since there are two decision makers, CPU0 and CPU2, both will send result requests. When CPU1 receives CPU0's result request.N=4, it refuses to send the calculation result to CPU0 because the condition judgment of result request.N≥agreed.N is not met. Therefore, the problem of two decision makers that appeared in the negotiation phase can be fixed in the decision phase, proving that this method can still operate normally.

[0102] like Figure 2 As shown, in combination with an embodiment of the present invention, a multi-CPU distributed negotiation control device for aerospace flight control is provided, comprising:

[0103] A negotiation module is used for each control cycle of a space launch vehicle's flight control. Before calculating various sensor data and / or rocket body equipment operating status information, any available CPU node acts as a negotiator to negotiate with all CPU nodes via a high-speed bus to determine whether it is the decision maker for this control cycle. All CPU nodes determine whether to agree with the negotiator as the decision maker for this control cycle based on preset rules. If the negotiator receives no less than a preset number of negotiation agreement response messages, it confirms that it is the decision maker for this control cycle. The number of CPU nodes is an odd number.

[0104] Responders, each of which performs calculations based on various sensor data and / or rocket equipment operating status information collected during this control cycle to obtain its own corresponding initial flight control solution results, wherein the responders are all CPU nodes;

[0105] The decision maker sends a result request to all responders to inquire about the initial flight control solution result;

[0106] The responder sends the initial flight control solution result corresponding to the responder to the verified decision maker;

[0107] The decision maker determines a final flight control solution result according to preset rules based on the received initial flight control solution result, and sends the final flight control solution result to a real-time bus. The final flight control solution result is used to control the operation of the space launch vehicle.

[0108] In a computing decision-making system, each flight control computing node is a module, and each flight control computing node has a CPU, so one CPU is also called one module. A multi-CPU distributed negotiation control method for aerospace flight control systems according to an embodiment of the present invention supports multi-mode systems with three or more modules. The flight control computer of a space launch vehicle performs real-time control of the equipment on the space launch vehicle at a fixed cycle (taking a 10ms operating cycle as an example). During each cycle, it collects sensor data and operating status from each module on the rocket body, performs calculations according to flight mission requirements, issues corresponding execution instructions to each controlled module within a 10ms cycle, and then waits for the next 10ms clock pulse interrupt to perform calculations and control for the next cycle.

[0109] Each CPU node, acting as a computing and communication node, plays the roles of negotiator, decision-maker, and responder. Each CPU node can play multiple roles simultaneously. Initially, the CPU node enters the negotiation phase, acting as both responder and negotiator. During the control phase, the CPU node acts as both decision-maker and responder. CPU nodes without decision-making power are merely responders, while decision-makers also serve as responders.

[0110] In an embodiment of the present invention, multiple CPUs negotiate within each control cycle to determine a CPU node as the decision maker, which issues comprehensive control instructions (including multiple timing control comprehensive instructions) for that control cycle (e.g., each control cycle is 10ms). That is, each control cycle requires multiple CPUs to negotiate to determine the decision maker for each round, who ultimately issues the control instructions for that round. This allows for synchronized and coordinated decision-making among multiple CPUs, ensuring that the initial solution results of multiple (odd number of) CPUs are ultimately unified into a final flight control settlement result, which is sent to the actuator as the control result for controlling the operation of the space launch vehicle.

[0111] Without relying on the assistance of other hardware and systems on the rocket, an effective control method can be formed at the software and algorithm level, allowing multi-mode flight control to interact and compare to form control results. Then, when one of the flight control computing nodes fails, the final flight control settlement result can still be obtained, thus achieving redundant control.

[0112] Preferably, the CPU node collects various sensor data and / or rocket body equipment operating status information on the space launch vehicle from the real-time bus, so that each CPU node can perform flight control calculations;

[0113] After confirming that it is the decision maker of this control cycle, the negotiator notifies all CPU nodes on the real-time bus that it is the decision maker of this control cycle, so that the respondent obtains the information of who is the decision maker.

[0114] Preferably, the multi-CPU distributed negotiation control device for aerospace flight control further includes:

[0115] The numbering module is used to set a unique digital number for each CPU node when setting the CPU node.

[0116] Among them, the negotiation module is also used to form, in each control cycle, each CPU node's own self-incrementing number in the current control cycle based on the unique digital number and the self-incrementing number of the previous control cycle, wherein the initial value of the self-incrementing number of each CPU node is its own unique digital number.

[0117] Specifically, K is used to represent the total number of CPU nodes, and J is a unique digital number for each CPU node. The recommended value of J is 0 to (K-1). Assuming K is 3, the J values of the three CPU nodes are 0, 1, and 2 respectively. For each CPU node, each CPU node uses a unidirectionally increasing, global, non-unique digital number in each control cycle, and the symbol N is used to represent the digital number. It is recommended to use a 64-bit unsigned integer to represent N, which can ensure that N will not overflow during the life cycle of the rocket flight control (that is, there will be no duplication errors). If the flight control of a space launch vehicle uses a control cycle of 10ms (also called a solution cycle), each CPU node must calculate its own N at the beginning of each control cycle, that is, before sending a negotiation request at the beginning of each 10ms, each CPU node performs a self-increment operation to obtain its own N: symbol express Round up; assuming that N increments once per solution cycle, it requires 2.13504*10 12 / K day is about 5.85*10 9 Overflow will occur only after / K years.

[0118] Preferably, the negotiation module is specifically configured to: any available CPU node as a negotiator sends a negotiation request to all CPU nodes via a high-speed bus, wherein the keywords of the negotiation request include: a negotiation field and the negotiator's own self-incrementing number;

[0119] Responder: After receiving the negotiation request, each CPU node as a responder determines whether the self-incrementing number of the negotiator in the negotiation request is greater than the self-incrementing number of the decision maker agreed by the CPU node in the previous control cycle; if so, it sends a negotiation approval response message to the negotiator, agreeing to the negotiator as the decision maker, and the CPU node that sent the negotiation approval response message records the self-incrementing number of the decision maker it agreed to; otherwise, it sends a negotiation rejection response message to the negotiator, rejecting the negotiator as the decision maker;

[0120] Decision maker: If the number of negotiation agreement response messages received is not less than half of the number of CPU nodes, it determines itself as the decision maker of this control cycle.

[0121] Specifically, the communication message types between different roles are described as follows:

[0122] Negotiation request: (negotiation.N); where N is the negotiator, indicating that the negotiation request is issued by N and is used to negotiate with N as the decision maker;

[0123] Negotiation response: (agree.N); indicates that another CPU node agrees that N is the decision maker;

[0124] Result request: (request.N); indicates that N issues a result request;

[0125] Result response: (result.N, calculation result); indicates that the calculation result has been sent to N;

[0126] Reject response: (reject.N); indicates refusal to send the initial flight control solution result to N.

[0127] Each CPU node also needs to maintain an agreed number N value. At the beginning, that is, before entering the first control cycle, each CPU node needs to set an initial value of the self-incrementing number of the decision maker of the response request that has been agreed. The initial value represents the decision maker of the response request that it has agreed to. The initial value is set to the CPU node's own unique digital number, that is, agreed. N = J, where J is the unique number of the CPU node.

[0128] To determine the decision-maker for the current solution cycle, each CPU node has the right to send a negotiation request to all responders. The request content is (negotiate.N), where the negotiation field contains the word "negotiate" and the negotiator's self-incrementing number is N. Negotiate.N is calculated using the self-incrementing formula (negotiate.N = agreed.N + J + 1). The request is made to become the decision-maker for the current solution cycle. After receiving the negotiation request, the responder can only send a negotiation approval reply message to the negotiator, agreeing to assign the negotiator the decision-maker role, only if Negotiate.N > its previous agreed number (the number it previously agreed to). The negotiation approval reply message contains (agree.N). Otherwise, a negotiation rejection reply message is sent, containing (reject.N). This ensures the legitimacy of each decision round and can also determine the decision-maker even if individual CPU nodes fail, ensuring the normal operation of flight control solutions.

[0129] After the responder agrees to the negotiator becoming the decision maker, the responder needs to record the agreed (negotiation.N), assign a value (agreement.N = negotiation.N), and no longer accept new negotiation requests (negotiation.N ≤ agreed.N). At the same time, the responder cannot accept result requests (request.N < agreed.N). Each reply message of the responder contains the response number (response.N = agreed.N) to ensure accuracy of subsequent work.

[0130] And because the number of CPU nodes is an odd number, combined with the judgment principle of determining negotiation, if When (round down) CPU nodes have abnormalities, this negotiation control method can still be executed normally.

[0131] Decision maker: If the number of negotiation agreement response messages received by the negotiator is less than half of the number of CPU nodes, then after waiting for the floating time interval, a new negotiation request is sent to all CPU nodes via the high-speed bus.

[0132] If the negotiator has not received the consent of more than half of the responders and has not sent a negotiation response of consent, it can wait for J*0.1+r (r is a random floating point number between 0 and 0.1) milliseconds and then send a negotiation request again, where the self-increment operation is used to obtain its own N: symbol express This random waiting process, rounded up, can resolve livelock during negotiation. Livelock occurs when two CPU nodes initiate simultaneous requests, making it impossible to determine which is the more appropriate decision-maker. The two CPU nodes must wait for the next round of negotiation, using a floating interval (J*0.1+r (r is a random floating point number between 0 and 0.1) milliseconds) associated with their unique numbers. If the waiting time is the same, the two CPU nodes will wait indefinitely, resulting in livelock.

[0133] Preferably, the decision maker is used to send a result request to all responders to inquire about the initial flight control solution result, and the keywords of the result request include: a result field and a self-incrementing number of the decision maker;

[0134] The responder is used to send a result response message to the decision maker corresponding to the result request if the self-incrementing number of the decision maker in the result request received by the responder is greater than or equal to the self-incrementing number of the decision maker agreed by the responder in this control cycle; otherwise, a result rejection response message is sent to the decision maker corresponding to the result request.

[0135] During the decision-making phase, the decision-maker sends a result request to all responders, who then respond or refuse to respond. The responder that receives the result request responds to the decision-maker that has been verified by the numbering judgment rule: If result request.N ≥ agreed.N, the responder uses its own initial flight control solution result as the response content: (result.N, calculation result) to form a result send response message and sends it to the decision-maker; otherwise, it sends a result rejection response message to the decision-maker. Based on the characteristics of the self-incrementing number formation, the self-incrementing number of the decision-maker that the responder agrees with is used to control whether the initial flight control solution result is sent to the decision-maker that sent the result request, thereby sending the flight control solution result to as few decision-makers as possible, ensuring that only a unique decision-maker can form a flight control solution result.

[0136] Preferably, the decision maker is configured to, if there are two or more decision makers, each decision maker sends a result request to all responders to inquire about the initial flight control solution result;

[0137] The responder is used to send a result reply message of the obtained initial flight control solution to the decision maker corresponding to the previous result request when there are two or more result requests, if the self-incrementing number of the decision maker in the previous result request received by the responder is greater than or equal to the self-incrementing number of the decision maker agreed by the responder in the current control cycle; otherwise, a result rejection reply message is sent to the decision maker in the previous result request;

[0138] If the self-incrementing number of the decision maker in the subsequent result request received by the respondent is smaller than the self-incrementing number of the decision maker in the previous result request, a result rejection response message is sent to the decision maker corresponding to the subsequent result request;

[0139] If the self-incrementing number of the decision maker in the subsequent result request received by the respondent is greater than the self-incrementing number of the decision maker in the previous result request, and the self-incrementing number of the decision maker in the subsequent result request is the self-incrementing number of the decision maker agreed by the respondent, then a result sending reply message is sent to the decision maker corresponding to the subsequent result request, and the self-incrementing number of the negotiator agreed by the respondent is updated to the self-incrementing number of the decision maker in the subsequent result request;

[0140] If the self-incrementing number of the decision maker in the subsequent result request received by the respondent is greater than the self-incrementing number of the decision maker in the previous result request, and the self-incrementing number of the decision maker in the subsequent result request is not the self-incrementing number of the decision maker agreed by the respondent, then a result rejection response message is sent to the decision maker corresponding to the subsequent result request;

[0141] The respondent receives the previous result request earlier than the respondent receives the next result request.

[0142] If high-speed bus data message loss occurs during the negotiation control process, the distributed negotiation control device can still be controlled to operate normally through the negotiation and decision-making process; even if multiple decision makers appear in the negotiation stage, the self-incrementing number of the decision maker agreed by oneself is used to control whether the initial flight control solution result is sent to the decision maker who sent the result request according to the formation characteristics of the self-incrementing number, so that the flight control solution result is sent to as few decision makers as possible, and it is still possible to achieve the preset process in the decision stage to let the truly appropriate decision maker make the decision, and ensure that only a unique decision maker can form the flight control solution result.

[0143] Preferably, the decision maker: if the initial flight control solution results received from the respondent are different, the settlement result is selected according to the rule of minority obeys majority, and when there are more than two different initial flight control settlement results, the two most recent initial flight control solution results are selected, and the arithmetic average of the two closest flight control settlement results is used as the final flight control solution result.

[0144] If the decision maker receives the initial flight control solution sent by more than half of the responders, half means Express The decision maker can summarize the received initial flight control solution results, or if no more than half of the responders have sent initial flight control solution results, collect as many initial flight control solution results as possible, and make a comprehensive judgment to determine the final flight control solution result within this control cycle.

[0145] In combination with an embodiment of the present invention, a space launch vehicle is also provided, comprising any one of the aforementioned multi-CPU distributed negotiation control devices for space flight control.

[0146] The beneficial technical effects achieved by the embodiments of the present invention are as follows:

[0147] Each CPU node, acting as a computing and communication node, plays the roles of negotiator, decision-maker, and responder. Each CPU node can play multiple roles simultaneously. Initially, the CPU node enters the negotiation phase, acting as both responder and negotiator. During the control phase, the CPU node acts as both decision-maker and responder. CPU nodes without decision-making power are merely responders, while decision-makers also serve as responders.

[0148] In an embodiment of the present invention, multiple CPUs negotiate within each control cycle to determine a CPU node as the decision maker, which issues comprehensive control instructions (including multiple timing control comprehensive instructions) for that control cycle (e.g., each control cycle is 10ms). That is, each control cycle requires multiple CPUs to negotiate to determine the decision maker for each round, who ultimately issues the control instructions for that round. This allows for synchronized and coordinated decision-making among multiple CPUs, ensuring that the initial solution results of multiple (odd number of) CPUs are ultimately unified into a final flight control settlement result, which is sent to the actuator as the control result for controlling the operation of the space launch vehicle.

[0149] Without relying on the assistance of other hardware and systems on the rocket, an effective control method can be formed at the software and algorithm level, allowing multi-mode flight control to interact and compare to form control results. Then, when one of the flight control computing nodes fails, the final flight control settlement result can still be obtained, thus achieving redundant control.

[0150] In a distributed system with K CPU nodes, a decision maker can be found in each solution cycle to collect the initial flight control solution results of all nodes and form the final flight control solution result for issuing control instructions; because the number of CPU nodes is an odd number, combined with the judgment principle of determining negotiation, (rounded down) CPU nodes are abnormal, it can still work normally; if high-speed bus data message is lost during the negotiation control process, the distributed negotiation control can still operate normally through the negotiation and decision-making process; even if there are multiple decision makers in the negotiation stage, it can still be achieved in the decision stage that the truly appropriate decision maker issues control instructions according to the preset process.

[0151] It should be understood that the specific order or hierarchy of steps in the disclosed processes is an example of an exemplary method. Based on design preferences, it should be understood that the specific order or hierarchy of steps in the process can be rearranged without departing from the scope of the present disclosure. The accompanying method claims present elements of the various steps in an exemplary order and are not intended to be limited to the specific order or hierarchy described.

[0152] In the foregoing detailed description, various features are grouped together in a single embodiment to simplify the disclosure. This method of disclosure should not be interpreted as reflecting an intention that embodiments of the claimed subject matter require more features than are expressly recited in each claim. On the contrary, as reflected in the appended claims, the invention comprises less than all the features of any individual disclosed embodiment. The appended claims are hereby expressly incorporated into the detailed description, with each claim standing on its own as a separate preferred embodiment of the invention.

[0153] The above description of the disclosed embodiments is intended to enable any person skilled in the art to implement or use the present invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments without departing from the spirit and scope of the present disclosure. Therefore, the present disclosure is not limited to the embodiments presented herein but is intended to be accorded the widest scope consistent with the principles and novel features disclosed herein.

[0154] The foregoing description includes examples of one or more embodiments. Of course, it is not possible to describe all possible combinations of components or methods for the purposes of describing the above embodiments, but one of ordinary skill in the art will recognize that the various embodiments may be further combined and arranged. Therefore, the embodiments described herein are intended to encompass all such changes, modifications and variations that fall within the scope of the appended claims. Furthermore, to the extent the term "comprising" is used in the specification or claims, the term is intended to be encompassed in a manner similar to the term "including," as explained in terms of "including," used as a transitional word in the claims. Furthermore, any use of the term "or" in the specification of the claims is intended to mean a "non-exclusive or."

[0155] Those skilled in the art will also appreciate that the various illustrative logical blocks, units, and steps listed in the embodiments of the present invention can be implemented by electronic hardware, computer software, or a combination of the two. To clearly demonstrate the interchangeability of hardware and software, the various illustrative components, units, and steps described above have generally described their functions. Whether such functions are implemented by hardware or software depends on the specific application and the design requirements of the entire system. Those skilled in the art may use various methods to implement the described functions for each specific application, but such implementation should not be understood as exceeding the scope of protection of the embodiments of the present invention.

[0156] The various illustrative logic blocks or units described in the embodiments of the present invention can be implemented or operated by a general-purpose processor, a digital signal processor, an application-specific integrated circuit (ASIC), a field programmable gate array or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof. The general-purpose processor can be a microprocessor, and optionally, the general-purpose processor can also be any conventional processor, controller, microcontroller or state machine. The processor can also be implemented by a combination of computing devices, such as a digital signal processor and a microprocessor, a plurality of microprocessors, one or more microprocessors combined with a digital signal processor core, or any other similar configuration.

[0157] The steps of the methods or algorithms described in the embodiments of the present invention may be directly embedded in hardware, a software module executed by a processor, or a combination of the two. The software module may be stored in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. For example, the storage medium may be connected to the processor so that the processor can read information from the storage medium and write information to the storage medium. Alternatively, the storage medium may also be integrated into the processor. The processor and storage medium may be provided in an ASIC, which may be provided in a user terminal. Alternatively, the processor and storage medium may also be provided in different components in the user terminal.

[0158] In one or more exemplary designs, the above-mentioned functions described in the embodiments of the present invention can be implemented in hardware, software, firmware, or any combination of the three. If implemented in software, these functions can be stored on a computer-readable medium or transmitted in the form of one or more instructions or codes on a computer-readable medium. Computer-readable media include computer storage media and communication media that facilitate the transfer of computer programs from one location to another. Storage media can be any available medium that can be accessed by a general or special computer. For example, such computer-readable media can include but are not limited to RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to carry or store program code in the form of instructions or data structures and other forms that can be read by a general or special computer, or a general or special processor. In addition, any connection can be appropriately defined as a computer-readable medium. For example, if the software is transmitted from a website, server or other remote resource via a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless methods such as infrared, wireless, and microwave, it is also included in the definition of computer-readable media. The disks and discs mentioned above include compact disks, laser disks, optical disks, DVDs, floppy disks, and Blu-ray discs. Disks typically reproduce data magnetically, while discs typically reproduce data optically with lasers. Combinations of the above may also be included in computer-readable media.

[0159] The specific implementation methods described above further illustrate the objectives, technical solutions and beneficial effects of the present invention in detail. It should be understood that the above description is only a specific implementation method of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the scope of protection of the present invention.

Claims

1. A multi-CPU distributed negotiation control method for aerospace flight control, characterized in that: include: Step 1: During each control cycle of a space launch vehicle's flight control, before calculating various sensor data and / or rocket body equipment operating status information, any available CPU node acts as a negotiator to negotiate with all CPU nodes via a high-speed bus to determine whether it is the decision maker for this control cycle. All CPU nodes determine whether to agree with the negotiator as the decision maker for this control cycle based on preset rules. If the negotiator receives no less than a preset number of negotiation agreement response messages, it confirms that it is the decision maker for this control cycle. The number of CPU nodes is an odd number. Step 2: Each responder performs calculations based on various sensor data and / or rocket equipment operating status information collected during this control cycle to obtain their respective initial flight control calculation results, where the responders are all CPU nodes; Step 3: The decision maker sends a result request to all responders to inquire about the initial flight control solution result; Step 4: The responder sends the initial flight control solution corresponding to the responder to the verified decision maker; Step 5: The decision maker determines the final flight control solution result according to the received initial flight control solution result according to preset rules, and sends the final flight control solution result to the real-time bus. The final flight control solution result is used to control the operation of the space launch vehicle.

2. The multi-CPU distributed negotiation control method for aerospace flight control according to claim 1, characterized in that: Also includes: Step 6: All CPU nodes collect various sensor data and / or operating status information of the rocket body equipment on the space launch vehicle from the real-time bus; wherein step 6 is executed in parallel with step 1; Step 7: After the negotiator confirms that it is the decision maker of this control cycle, the decision maker notifies all CPU nodes on the real-time bus that it is the decision maker of this control cycle.

3. The multi-CPU distributed negotiation control method for aerospace flight control according to claim 1, characterized in that: Also includes: Step 8: Set a unique digital number for each CPU node, wherein step 8 is performed before step 6; Among them, step 1 also includes: in each control cycle, each CPU node forms its own self-incrementing number in the current control cycle based on the unique digital number and the self-incrementing number of the previous control cycle, wherein the initial value of the self-incrementing number of each CPU node is its own unique digital number.

4. The multi-CPU distributed negotiation control method for aerospace flight control according to claim 3, characterized in that: In step 1, all the CPU nodes determine whether to agree with the negotiator as the decision maker of this control cycle according to preset rules, which specifically includes: Any available CPU node acts as a negotiator and sends a negotiation request to all CPU nodes via the high-speed bus. The keywords of the negotiation request include: a negotiation field and the negotiator's own self-incrementing number; After receiving the negotiation request, each CPU node determines whether the self-incrementing number of the negotiator in the negotiation request is greater than the self-incrementing number of the decision maker agreed by the CPU node in the previous control cycle; If it is greater than, a negotiation approval response message is sent to the negotiator, agreeing that the negotiator is the decision maker, and the CPU node that sends the negotiation approval response message records the self-increment number of the decision maker that it agrees with; otherwise, a negotiation rejection response message is sent to the negotiator, rejecting the negotiator as the decision maker; If the number of negotiation agreement response messages obtained by the negotiator is not less than half of the number of CPU nodes, the negotiator determines itself as the decision maker of this control cycle.

5. The multi-CPU distributed negotiation control method for aerospace flight control according to claim 4, characterized in that: Step 1, all the CPU nodes respectively determine whether to agree with the negotiator as the decision maker of this control cycle according to preset rules, and further includes: If the number of negotiation agreement response messages received by the negotiator is less than half of the number of CPU nodes, then after waiting for the floating time interval, a new negotiation request is sent to all CPU nodes via the high-speed bus.

6. The multi-CPU distributed negotiation control method for aerospace flight control according to claim 1, characterized in that: Step 3 specifically includes: The decision maker sends a result request to all responders to inquire about the initial flight control solution result, and the keywords of the result request include: a result field and a self-incrementing number of the decision maker; Step 4 specifically includes: If the self-incrementing number of the decision maker in the result request received by the respondent is greater than or equal to the self-incrementing number of the decision maker agreed by the respondent in this control cycle, the initial flight control solution result obtained will be sent to the decision maker corresponding to the result request in the form of a result sending response message; otherwise, a result rejection response message will be sent to the decision maker corresponding to the result request.

7. The multi-CPU distributed negotiation control method for aerospace flight control according to claim 6, characterized in that: Step 3 also includes: If there are two or more decision makers determined in step 1, each decision maker sends a result request to all responders to inquire about the initial flight control solution result; Step 4 specifically includes: When there are two or more result requests, if the self-incrementing number of the decision maker in the previous result request received by the responder is greater than or equal to the self-incrementing number of the decision maker agreed by the responder in the current control cycle, the initial flight control solution result is formed into a result sending reply message and sent to the decision maker corresponding to the previous result request; otherwise, a result rejection reply message is sent to the decision maker in the previous result request; If the self-incrementing number of the decision maker in the subsequent result request received by the respondent is smaller than the self-incrementing number of the decision maker in the previous result request, a result rejection response message is sent to the decision maker corresponding to the subsequent result request; If the self-incrementing number of the decision maker in the subsequent result request received by the respondent is greater than the self-incrementing number of the decision maker in the previous result request, and the self-incrementing number of the decision maker in the subsequent result request is the self-incrementing number of the decision maker agreed by the respondent, then a result sending reply message is sent to the decision maker corresponding to the subsequent result request, and the self-incrementing number of the negotiator agreed by the respondent is updated to the self-incrementing number of the decision maker in the subsequent result request; If the self-incrementing number of the decision maker in the subsequent result request received by the respondent is greater than the self-incrementing number of the decision maker in the previous result request, and the self-incrementing number of the decision maker in the subsequent result request is not the self-incrementing number of the decision maker agreed by the respondent, then a result rejection response message is sent to the decision maker corresponding to the subsequent result request; The respondent receives the previous result request earlier than the respondent receives the next result request.

8. The multi-CPU distributed negotiation control method for aerospace flight control according to claim 1, characterized in that: Step 5 specifically includes: If the initial flight control solution results received by the decision maker from the respondent are different, the settlement result is selected according to the rule of minority obeys majority, and when there are more than two different initial flight control settlement results, the two most recent initial flight control solution results are selected, and the arithmetic average of the two closest flight control settlement results is used as the final flight control solution result.

9. A multi-CPU distributed negotiation control device for aerospace flight control, characterized in that: include: A negotiation module is used for each control cycle of a space launch vehicle's flight control. Before calculating various sensor data and / or rocket body equipment operating status information, any available CPU node acts as a negotiator to negotiate with all CPU nodes via a high-speed bus to determine whether it is the decision maker for this control cycle. All CPU nodes determine whether to agree with the negotiator as the decision maker for this control cycle based on preset rules. If the negotiator receives no less than a preset number of negotiation agreement response messages, it confirms that it is the decision maker for this control cycle. The number of CPU nodes is an odd number. Responders, which are all CPU nodes, are used to perform calculations based on various sensor data and / or rocket equipment operating status information collected during this control cycle to obtain their respective corresponding initial flight control solution results; The decision maker is configured to send a result request to all responders to inquire about the initial flight control solution result; The responder is further configured to send the initial flight control solution result corresponding to the responder to the verified decision maker; The decision maker is further used to determine the final flight control solution result according to the received initial flight control solution result according to preset rules, and send the final flight control solution result to the real-time bus. The final flight control solution result is used to control the operation of the space launch vehicle.

10. A space launch vehicle, characterized in that: It includes the multi-CPU distributed negotiation control device for aerospace flight control as described in claim 9.

Images