A spaceflight control multi-cpu distributed negotiation control method and device and rocket

Abstract

The embodiment of the application provides a kind of spaceflight flight control's multi-CPU distributed negotiation control method, device and rocket, which comprises the following steps: in each control cycle of space launch vehicle flight control, any available CPU node negotiates with all CPU nodes to determine itself as the decision maker of the control cycle, if the negotiator gets not less than the preset number of negotiation agreement response message, it confirms itself as the decision maker of the control cycle;The solver respectively carries out calculation, obtains the initial flight control calculation result corresponding to each other, and the decision maker sends the result request to all responders to inquire the initial flight control calculation result;The initial flight control calculation result corresponding to the responder is sent to the decision maker verified;The decision maker determines the final flight control calculation result according to the received initial flight control calculation result according to the preset rule.When any CPU node fails, the final flight control settlement result can still be obtained, and redundant control is realized.

Description

Technical Field

[0001] This invention relates to the aerospace field, specifically to a multi-CPU distributed negotiation control method, device, and rocket for aerospace flight control. Background Technology

[0002] Traditionally, the flight control computer on a space launch vehicle has only one core CPU control unit. However, with the advancement of computer technology, the use of multiple flight control computing nodes (CPU nodes) to independently perform parallel calculations for flight control calculations on the flight control system of space launch vehicles is about to become the mainstream technology.

[0003] In the process of developing this invention, the applicant discovered at least the following problems in the prior art:

[0004] Although multi-mode flight control computing nodes are currently being deployed in various space launch vehicles, they still rely on other hardware and systems on the space launch vehicle to complete the task. They have not yet "formed an effective control method at the software and algorithm level to enable multi-mode flight controllers to interact and compare to form decisions, so as to achieve redundant control in the event of a failure." Summary of the Invention

[0005] This invention provides 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 other hardware and systems on the aerospace launch vehicles to complete the task, and cannot form an effective control method at their own software and algorithm level to enable multi-mode flight control to interact and compare to form decisions so as to achieve redundant control in the event of a failure".

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

[0007] Step 1: In each control cycle of the space launch vehicle's flight control, before processing various sensor data and / or the operational status information of the rocket body equipment, any available CPU node acts as a negotiator and negotiates with all CPU nodes via a high-speed bus to determine itself as 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 according to preset rules. If the negotiator receives no less than a preset number of negotiation agreement response messages, it confirms itself as the decision-maker for this control cycle. The number of CPU nodes is odd.

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

[0009] Step 3: The decision-maker sends a result request to all respondents to inquire about the initial flight control calculation results;

[0010] Step 4: The respondent sends its corresponding initial flight control calculation result to the verified decision-maker;

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

[0012] Secondly, embodiments of the present invention provide a multi-CPU distributed negotiation control device for aerospace flight control, comprising:

[0013] The negotiation module is used for each control cycle of the flight control of the space launch vehicle. Before processing various sensor data and / or the operating status information of the rocket body equipment, any available CPU node acts as a negotiator and negotiates with all CPU nodes through a high-speed bus to determine itself as 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 according to preset rules. If the negotiator receives no less than a preset number of negotiation agreement response messages, it confirms itself as the decision-maker for this control cycle. The number of CPU nodes is odd.

[0014] Each responder performs calculations based on various sensor data and / or rocket body equipment operating status information collected during this control cycle to obtain its own corresponding initial flight control calculation results. The responders are all CPU nodes.

[0015] The decision-maker sends a result request to all respondents to inquire about the initial flight control calculation results;

[0016] The respondent sends its corresponding initial flight control calculation result to the verified decision-maker;

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

[0018] Thirdly, embodiments of the present invention provide a space launch vehicle, including 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, serving as a computing and communication node, plays three roles: negotiator, decision-maker, and responder. Each CPU node can simultaneously assume multiple roles. Initially, during the negotiation phase, the CPU node acts as both a responder and a negotiator. In the control phase, the CPU node acts as both a decision-maker and a responder. CPU nodes that do not acquire decision-making power are merely responders, and decision-makers are also responders.

[0021] In this embodiment of the invention, multiple CPUs first negotiate within each control cycle to determine one CPU node as the decision-maker, which then issues the comprehensive control command (including comprehensive commands of multiple timing controls) for the current control cycle (e.g., each control cycle is 10ms). That is, in each control cycle, multiple CPUs need to negotiate to determine the decision-maker for each round, and this decision-maker ultimately issues the control command for that round. This enables synchronous and coordinated decision-making among multiple CPUs, ensuring that the initial calculation results of multiple (odd number) CPUs are ultimately unified into a single final flight control settlement result, which is then sent as the control result to the actuator to control the operation of the space launch vehicle.

[0022] The embodiments of the present invention do not require the assistance of other hardware and systems on the rocket to complete the task. They can form an effective control method at their own software and algorithm level, enabling multi-mode flight controllers to interact and compare to form control results. Even if one of the flight control computing nodes fails, the final flight control calculation result can still be obtained, thus achieving redundant control. Attached Figure Description

[0023] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0024] Figure 1 This is a flowchart of a multi-CPU distributed negotiation control method for aerospace launch vehicle flight control 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 aerospace launch vehicle flight control according to an embodiment of the present invention;

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

[0027] Figure 4 This is a description of the roles and message types in embodiments 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 illustrating the process of reaching a consensus through multiple negotiations according to an embodiment of the present invention;

[0030] Figure 7 This is a schematic diagram illustrating the intermediate packet loss process and the eventual consensus reached in an embodiment of the present invention. Detailed Implementation

[0031] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

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

[0033] Step 1: In each control cycle of the space launch vehicle's flight control, before processing various sensor data and / or the operational status information of the rocket body equipment, any available CPU node acts as a negotiator and negotiates with all CPU nodes via a high-speed bus to determine itself as 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 according to preset rules. If the negotiator receives no less than a preset number of negotiation agreement response messages, it confirms itself as the decision-maker for this control cycle. The number of CPU nodes is odd, with at least three.

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

[0035] Step 3: The decision-maker sends a result request to all respondents to inquire about the initial flight control calculation results;

[0036] Step 4: The respondent sends its corresponding initial flight control calculation result to the verified decision-maker;

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

[0038] The multi-CPU flight control system of aerospace launch vehicles is equipped with 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 configuration with one master device and multiple slave devices, (3) devices listen to 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, (3) a collision detection and retransmission mechanism, which does not guarantee reliable transmission, and (4) support for simultaneous transmission and reception by multiple terminals.

[0039] The flight control system of a space launch vehicle comprises a sensing system, a computing and decision-making system, actuators, 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 typical master-slave real-time buses used in aerospace systems to connect the sensing and real-time control systems on the space launch vehicle. Ethernet is a typical high-speed bus used in aerospace control systems to connect the real-time control system and the telemetry system for non-real-time communication. The onboard control system connected by these two buses is shown below. Figure 3 As shown, for the sake of simplicity, the examples all use a system with 3 CPUs as the typical case.

[0040] In a computational decision-making system, each flight control computing node is a module, and each flight control computing node has a CPU; therefore, a CPU is also called a module. This invention provides a multi-CPU distributed negotiation control method for aerospace flight control, supporting multi-mode systems with three or more modules. The flight control computer of the aerospace launch vehicle performs real-time control of the equipment on the launch vehicle at a fixed cycle (taking 10ms as an example). Within each cycle, it needs to collect sensor data and operating status of each module on the rocket body, perform calculations according to the flight mission requirements, and issue corresponding execution commands to each controlled module within one cycle (10ms). Then, it waits for the next 10ms clock pulse interruption before starting the calculation and control for the next cycle.

[0041] Each CPU node, serving as a computing and communication node, plays three roles: negotiator, decision-maker, and responder. Each CPU node can simultaneously assume multiple roles. Initially, during the negotiation phase, the CPU node acts as both a responder and a negotiator. In the control phase, the CPU node acts as both a decision-maker and a responder. CPU nodes that do not acquire decision-making power are merely responders, and decision-makers are also responders.

[0042] In this embodiment of the invention, multiple CPUs first negotiate within each control cycle to determine one CPU node as the decision-maker, which then issues the comprehensive control command (including comprehensive commands of multiple timing controls) for the current control cycle (e.g., each control cycle is 10ms). That is, in each control cycle, multiple CPUs need to negotiate to determine the decision-maker for each round, and this decision-maker ultimately issues the control command for that round. This enables synchronous and coordinated decision-making among multiple CPUs, ensuring that the initial calculation results of multiple (odd number) CPUs are ultimately unified into a single final flight control settlement result, which is then sent as the control result to the actuator to control the operation of the space launch vehicle.

[0043] Without relying on other hardware and systems on the rocket, it can form an effective control method at its own software and algorithm level, enabling multi-mode flight controllers to interact and compare to form control results. Even if one of the flight control computing nodes fails, the final flight control calculation result can still be obtained, 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 rocket body equipment operating status information from the real-time bus for flight control calculations on each CPU node; Step 6 is executed in parallel with Step 1.

[0046] Step 7: After the negotiator confirms itself as the decision-maker for this control cycle, the decision-maker notifies all CPU nodes on the real-time bus that it is the decision-maker for this control cycle, so that the responders know who the decision-maker is.

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

[0048] Step 8: Assign a unique numerical number to each CPU node. Step 8 is performed before step 6.

[0049] Step 1 further includes: in each control cycle, each CPU node forms its own auto-incrementing number in the current control cycle based on the unique numerical number and the auto-incrementing number of the previous control cycle, wherein the initial value of the auto-incrementing number of each CPU node is its own unique numerical number.

[0050] Specifically, K represents the total number of CPU nodes, and J is a unique numerical identifier for each CPU node. J is recommended to range from 0 to (K-1). Assuming K is 3, the J values ​​for the three CPU nodes are 0, 1, and 2, respectively. For each CPU node, within each control cycle, each CPU node uses a unidirectionally incrementing, globally unique numerical identifier, represented by the symbol N. It is recommended that N be represented as a 64-bit unsigned integer to ensure that N will not overflow (i.e., will not repeat errors) during the rocket flight control system's lifecycle. If the space launch vehicle flight control system uses a 10ms control cycle (also called a solution cycle), each CPU node must calculate its own N at the beginning of each control cycle. That is, before issuing a negotiation request at the beginning of each 10ms, each CPU node performs an increment operation to obtain its own N. symbol express Round up; assuming the increment operation of N is performed once per solution cycle, it requires 2.13504 * 10^64. 12 / K days is approximately 5.85*10 9 Overflow will only occur in / K years.

[0051] Preferably, in step 1, each CPU node determines whether to agree to the negotiator as the decision-maker for this control cycle according to preset rules, specifically including:

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

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

[0054] If the value is greater than the value, a negotiation agreement response message agreeing to the negotiation as the decision-maker is sent to the negotiation party, and the CPU node that sends the negotiation agreement response message records the auto-incrementing number of the decision-maker it agrees to; otherwise, a negotiation rejection response message rejecting the negotiation party as the decision-maker is sent to the negotiation party.

[0055] If the number of consensus response messages received by the negotiator is not less than half the number of CPU nodes, then the negotiator determines itself as the decision-maker for this control cycle.

[0056] Specifically, the communication message types between the various roles are described below:

[0057] Negotiation request: (negotiation.N); where N is the negotiator, indicating that the negotiation request was 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 is issuing a result request;

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

[0061] Reject Response: (Reject.N); indicates a refusal to send the initial flight control solution results 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 an auto-incrementing number of the decision-maker of the response request that has been agreed. This initial value represents the decision-maker of the response request that it has agreed. This initial value is set as the CPU node's own unique number, that is, agreed. N = J, where J is the unique number of the CPU node.

[0063] To determine the decision-maker for this solution cycle, each CPU node has the right to send a negotiation request to all responders. The request content is (Negotiation.N), where the negotiation field contains the word "Negotiation," and the negotiator's own auto-incrementing ID is N. Negotiation.N uses an auto-incrementing formula, or it can be Negotiation.N = Agreed.N + J + 1, requesting to become the decision-maker for this solution cycle. After receiving the negotiation request, a responder can only send a negotiation agreement response message to the negotiator if Negotiation.N > its previous self.N (the ID it previously agreed to), agreeing to grant the negotiator the decision-maker role. The content of the negotiation agreement response message is (Agreed.N). Otherwise, a negotiation rejection response message is sent, with the content: (Rejection.N). This ensures the legitimacy of each round of decision-making and allows for the determination of the decision-maker even when individual CPU nodes fail, ensuring the normal operation of flight control solution.

[0064] After agreeing to let the negotiator become the decision-maker, the respondent needs to record the agreed-upon value (negotiation.N) and assign it the value (agreed.N = negotiation.N). The respondent will no longer accept new negotiation requests (negotiation.N ≤ agreed.N) and will not accept result requests (request.N < agreed.N). Each reply from the respondent includes the response number (response.N = agreed.N) to ensure accuracy for subsequent work.

[0065] And because the number of CPU nodes is odd, combined with the decision-making principle for the negotiation, if Even if (round down) CPU nodes malfunction, this negotiation control method can still be executed normally.

[0066] Preferably, in step 1, all CPU nodes determine whether to agree to the negotiator as the decision-maker for this control cycle according to preset rules, specifically including:

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

[0068] If a negotiator has not received consent from more than half of the respondents, and has not issued a consent response itself, it can resend the negotiation request after waiting for J*0.1+r (where r is a random floating-point number between 0 and 0.1) milliseconds, where the increment operation yields its own N: symbol express Rounding up, this random waiting process can resolve the livelock problem during the negotiation process. Livelock occurs when two CPU nodes simultaneously initiate requests, making it impossible to determine which is more suitable to become the decision-maker. They can only wait for a floating time interval (J*0.1+r, where r is a random floating-point number between 0 and 0.1) milliseconds, associated with their unique numerical identifier, to initiate the next round of negotiation. If the waiting time is the same, both CPU nodes will enter an infinite wait, resulting in a livelock.

[0069] Preferably, step 3 specifically includes:

[0070] The decision-maker sends a result request to all respondents to inquire about the initial flight control calculation results. The keywords of the result request include: the result field and the decision-maker's auto-incrementing number.

[0071] Step 4 specifically includes:

[0072] If the auto-incremented number of the decision-maker in the result request received by the responder is greater than or equal to the auto-incremented number of the decision-maker it agrees with in this control cycle, then the responder will send the obtained initial flight control calculation result as a result sending response message to the decision-maker corresponding to the result request; 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 either respond or refuse to respond. Responders receiving a result request respond to the decision-maker verified through a numbering rule: if the result request.N ≥ agreed.N, they send their initial flight control calculation result as the response content: (result.N, calculation result) forming a result-send response message to the decision-maker; otherwise, they send a result-rejection response message to the decision-maker. Based on the characteristics of auto-incrementing numbering, the decision-maker controls whether to send the initial flight control calculation result to the decision-maker who sent the result request by using the auto-incrementing number of the decision-maker they agree with. This ensures that the flight control calculation result is sent to as few decision-makers as possible, guaranteeing that only a unique decision-maker can generate a valid flight control calculation result.

[0074] Preferably, step 3 further includes:

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

[0076] Step 4 specifically includes:

[0077] When there are two or more result requests, if the auto-incremented number of the decision-maker in the previous result request received by the responder is greater than or equal to the auto-incremented number of the decision-maker it agrees with in the current control cycle, then the initial flight control calculation result obtained is formed into a result sending response message and sent to the decision-maker corresponding to the previous result request; otherwise, a result rejection response message is sent to the decision-maker in the previous result request.

[0078] If the auto-incremented number of the decision-maker in the subsequent result request received by the responder is less than the auto-incremented number of the decision-maker in the previous result request, then a result rejection response message is sent to the decision-maker corresponding to the subsequent result request.

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

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

[0081] In this case, the responder receives the previous result request before receiving the next result request.

[0082] Even if high-speed bus data messages are lost during the negotiation control process, the distributed negotiation control device can still operate normally through the negotiation and decision-making process. Even if multiple decision-makers appear during the negotiation phase, the initial flight control calculation result can be sent to the decision-maker who requests the result by using the auto-incrementing number of the decision-maker agreed upon by the decision-maker, based on the characteristics of the auto-incrementing number formation. This ensures that the flight control calculation result is sent to as few decision-makers as possible, and still achieves the goal of ensuring that the truly suitable decision-maker is selected according to the preset process during the decision-making phase. Only a unique decision-maker can form a flight control calculation result.

[0083] Preferably, step 5 specifically includes:

[0084] If the decision-maker receives different initial flight control calculation results from the respondent, the calculation result is selected according to the majority rule. When there are more than two different initial flight control calculation results, the two closest initial flight control calculation results are selected, and the arithmetic mean of the two closest flight control calculation results is used as the final flight control calculation result.

[0085] If the decision-maker receives initial flight control calculation results from more than half of the respondents, half means... Indicates to (After rounding down) the initial flight control calculation results of the responders, the decision-maker can summarize the received initial flight control calculation results, or, if no more than half of the responders send initial flight control calculation results, collect as many initial flight control calculation results as possible, and make a comprehensive judgment to determine the final flight control calculation result for this control cycle.

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

[0087] Negotiator: Each CPU node is a negotiator, which can send negotiation requests to all responders and wait for more than half of the valid responses before confirming itself as the decision-maker for this control cycle.

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

[0089] Respondent: Maintains its own ID N and agreed.N, accepts requests from negotiators and decision-makers, and provides a response according to the logical requirements below. The response can be a negotiation response, a result response, or a rejection response.

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

[0091] 1. Data Acquisition: The CPU node acquires various sensor data and operational status information of the rocket body equipment from the real-time bus;

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

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

[0094] 4. Each CPU node enters the flight control calculation stage, and 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 queries each CPU node (i.e., the responder) for the initial flight control calculation results. After completing this round of calculations, the responder sends the final flight control calculation results.

[0096] 6. During the decision-making phase, after the decision-maker receives the initial flight control calculation results from each responder, they can follow the majority rule. When the initial flight control calculation results of the CPU nodes are different, the arithmetic average of the two closest initial flight control calculation 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 illustrates a typical decision-making process for multi-CPU distributed negotiation control in aerospace flight control. For example... 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), respectively. Initially, they can be set to "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 announces to all nodes on the real-time bus that it has become the decision-maker.

[0098] During the decision-making phase, since CPU2 is the decision-maker, it sends a result request (result request.N=6) to all responders. Because all responders' (agreed.N=6) meet the condition (result request.N≥agreed.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 evaluation and sends the control command to the real-time bus, completing one cycle of flight control process.

[0099] Example 2: The process of completing negotiation after the negotiation process is rejected, such as... Figure 6 As shown, during the negotiation phase, it is assumed that due to factors such as packet loss on the high-speed network bus, the agreed-upon N values ​​of the three CPU nodes have become inconsistent during the previous operation. Specifically, when CPU2 sends negotiation requests to CPU1 and CPU0, they are rejected because the condition that negotiation N ≥ agreed-upon N is not met. Subsequently, CPU1 sends negotiation requests to CPU0 and CPU2. Since negotiation N = 11, which is greater than the agreed-upon N values ​​of CPU0 and CPU2, it receives an agreement response, thus determining that CPU1 has become the decision-maker.

[0100] Example 3: The process of multiple negotiations and finally reaching a consensus due to high-speed bus data packet loss, such as... Figure 7 As shown in (a), at the start of negotiation, assuming that the CPU nodes have already reached an agreement among the three CPUs during the previous operation, CPU0 sends a negotiation request to CPU1 and CPU2. Having received a response from CPU1, and combining it with its own response, although it did not receive a negotiation response from CPU2 due to network packet loss, because the number of responders is 2, exceeding half, CPU0 considers itself the decision-maker. Figure 7 As shown in (b), at this point, CPU2 believes that no legitimate decision-maker has emerged, so it also sends negotiation requests to CPU0 and CPU1. Suppose that network packet loss occurs again at this time, and CPU2 does not receive a response from CPU0. However, the responses from both CPU1 and CPU2 have determined that CPU2 can become the decision-maker, and at this time CPU1 has agreed. N=6.

[0101] Once the decision-making phase begins, there are two decision-makers, CPU0 and CPU2, both of whom 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 that result request N ≥ agreed N is not met. Therefore, the decision-making phase can fix the problem of two decision-makers that occurred in the negotiation phase, proving that the method can still operate normally.

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

[0103] The negotiation module is used for each control cycle of the flight control of the space launch vehicle. Before processing various sensor data and / or the operating status information of the rocket body equipment, any available CPU node acts as a negotiator and negotiates with all CPU nodes through a high-speed bus to determine itself as 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 according to preset rules. If the negotiator receives no less than a preset number of negotiation agreement response messages, it confirms itself as the decision-maker for this control cycle. The number of CPU nodes is odd.

[0104] Each responder performs calculations based on various sensor data and / or rocket body equipment operating status information collected during this control cycle to obtain its own corresponding initial flight control calculation results. The responders are all CPU nodes.

[0105] The decision-maker sends a result request to all respondents to inquire about the initial flight control calculation results;

[0106] The respondent sends its corresponding initial flight control calculation result to the verified decision-maker;

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

[0108] In a computational decision-making system, each flight control computing node is a module, and each flight control computing node has a CPU; therefore, a CPU is also called a module. This invention provides a multi-CPU distributed negotiation control method for aerospace flight control, supporting multi-mode systems with three or more modules. The flight control computer of the aerospace launch vehicle performs real-time control of the equipment on the launch vehicle at a fixed cycle (taking 10ms as an example). Within each cycle, it needs to collect sensor data and operating status of each module on the rocket body, perform calculations according to the flight mission requirements, and issue corresponding execution commands to each controlled module within one cycle (10ms). Then, it waits for the next 10ms clock pulse interruption before starting the calculation and control for the next cycle.

[0109] Each CPU node, serving as a computing and communication node, plays three roles: negotiator, decision-maker, and responder. Each CPU node can simultaneously assume multiple roles. Initially, during the negotiation phase, the CPU node acts as both a responder and a negotiator. In the control phase, the CPU node acts as both a decision-maker and a responder. CPU nodes that do not acquire decision-making power are merely responders, and decision-makers are also responders.

[0110] In this embodiment of the invention, multiple CPUs first negotiate within each control cycle to determine one CPU node as the decision-maker, which then issues the comprehensive control command (including comprehensive commands of multiple timing controls) for the current control cycle (e.g., each control cycle is 10ms). That is, in each control cycle, multiple CPUs need to negotiate to determine the decision-maker for each round, and this decision-maker ultimately issues the control command for that round. This enables synchronous and coordinated decision-making among multiple CPUs, ensuring that the initial calculation results of multiple (odd number) CPUs are ultimately unified into a single final flight control settlement result, which is then sent as the control result to the actuator to control the operation of the space launch vehicle.

[0111] Without relying on other hardware and systems on the rocket, it can form an effective control method at its own software and algorithm level, enabling multi-mode flight controllers to interact and compare to form control results. Even if one of the flight control computing nodes fails, the final flight control calculation result can still be obtained, achieving redundant control.

[0112] Preferably, the CPU node collects various sensor data and / or rocket body equipment operating status information from the real-time bus, which is used for flight control calculations by each CPU node;

[0113] After confirming itself as the decision-maker for this control cycle, the negotiator notifies all CPU nodes on the real-time bus that it is the decision-maker for this control cycle, so that the responders know who the decision-maker is.

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

[0115] The numbering module is used to assign a unique numerical number to each CPU node when configuring it.

[0116] The negotiation module is further configured to, in each control cycle, have each CPU node form its own auto-incrementing number for the current control cycle based on the unique numerical number and the auto-incrementing number of the previous control cycle, wherein the initial value of the auto-incrementing number of each CPU node is its own unique numerical number.

[0117] Specifically, K represents the total number of CPU nodes, and J is a unique numerical identifier for each CPU node. J is recommended to range from 0 to (K-1). Assuming K is 3, the J values ​​for the three CPU nodes are 0, 1, and 2, respectively. For each CPU node, within each control cycle, each CPU node uses a unidirectionally incrementing, globally unique numerical identifier, represented by the symbol N. It is recommended that N be represented as a 64-bit unsigned integer to ensure that N will not overflow (i.e., will not repeat errors) during the rocket flight control system's lifecycle. If the space launch vehicle flight control system uses a 10ms control cycle (also called a solution cycle), each CPU node must calculate its own N at the beginning of each control cycle. That is, before issuing a negotiation request at the beginning of each 10ms, each CPU node performs an increment operation to obtain its own N. symbol express Round up; assuming the increment operation of N is performed once per solution cycle, it requires 2.13504 * 10^64. 12 / K days is approximately 5.85*10 9 Overflow will only occur in / K years.

[0118] Preferably, the negotiation module is specifically used for: any available CPU node acting as a negotiator to send a negotiation request to all CPU nodes via a high-speed bus, the keywords of the negotiation request including: a negotiation field and the negotiator's own auto-incrementing number;

[0119] Respondent: Upon receiving the negotiation request, each CPU node, acting as a respondent, determines whether the auto-incrementing number of the negotiator in the negotiation request is greater than the auto-incrementing number of the decision-maker agreed upon by the CPU node in the previous control cycle. If it is greater, the CPU node sends a negotiation agreement response message to the negotiator, agreeing that the negotiator should be the decision-maker. The CPU node that sends the negotiation agreement response message records the auto-incrementing number of the decision-maker it has agreed upon. Otherwise, the CPU node sends a negotiation rejection response message to the negotiator, rejecting the negotiator from being the decision-maker.

[0120] Decision maker: If the number of consensus response messages obtained is not less than half the number of CPU nodes, then the decision maker shall determine itself as the decision maker for this control cycle.

[0121] Specifically, the communication message types between the various roles are described below:

[0122] Negotiation request: (negotiation.N); where N is the negotiator, indicating that the negotiation request was 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 is issuing a result request;

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

[0126] Reject Response: (Reject.N); indicates a refusal to send the initial flight control solution results 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 an auto-incrementing number of the decision-maker of the response request that has been agreed. This initial value represents the decision-maker of the response request that it has agreed. This initial value is set as the CPU node's own unique number, that is, agreed. N = J, where J is the unique number of the CPU node.

[0128] To determine the decision-maker for this solution cycle, each CPU node has the right to send a negotiation request to all responders. The request content is (Negotiation.N), where the negotiation field contains the word "Negotiation," and the negotiator's own auto-incrementing ID is N. Negotiation.N uses an auto-incrementing formula, or it can be Negotiation.N = Agreed.N + J + 1, requesting to become the decision-maker for this solution cycle. After receiving the negotiation request, a responder can only send a negotiation agreement response message to the negotiator if Negotiation.N > its previous self.N (the ID it previously agreed to), agreeing to grant the negotiator the decision-maker role. The content of the negotiation agreement response message is (Agreed.N). Otherwise, a negotiation rejection response message is sent, with the content: (Rejection.N). This ensures the legitimacy of each round of decision-making and allows for the determination of the decision-maker even when individual CPU nodes fail, ensuring the normal operation of flight control solution.

[0129] After agreeing to let the negotiator become the decision-maker, the respondent needs to record the agreed-upon value (negotiation.N) and assign it the value (agreed.N = negotiation.N). The respondent will no longer accept new negotiation requests (negotiation.N ≤ agreed.N) and will not accept result requests (request.N < agreed.N). Each reply from the respondent includes the response number (response.N = agreed.N) to ensure accuracy for subsequent work.

[0130] And because the number of CPU nodes is odd, combined with the decision-making principle for the negotiation, if Even if (round down) CPU nodes malfunction, 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 the number of CPU nodes, then after waiting for a floating time interval, a new negotiation request is sent to all CPU nodes via the high-speed bus.

[0132] If a negotiator has not received consent from more than half of the respondents, and has not issued a consent response itself, it can resend the negotiation request after waiting for J*0.1+r (where r is a random floating-point number between 0 and 0.1) milliseconds, where the increment operation yields its own N: symbol express Rounding up, this random waiting process can resolve the livelock problem during the negotiation process. Livelock occurs when two CPU nodes simultaneously initiate requests, making it impossible to determine which is more suitable to become the decision-maker. They can only wait for a floating time interval (J*0.1+r, where r is a random floating-point number between 0 and 0.1) milliseconds, associated with their unique numerical identifier, to initiate the next round of negotiation. If the waiting time is the same, both CPU nodes will enter an infinite wait, resulting in a livelock.

[0133] Preferably, the decision-maker is used to send a result request to all respondents to inquire about the initial flight control calculation result, wherein the keywords of the result request include: the result field and the decision-maker's auto-incrementing number;

[0134] The responder is configured to send the initial flight control calculation result as a result sending response message to the decision-maker corresponding to the result request if the auto-incremented number of the decision-maker in the result request received by the responder is greater than or equal to the auto-incremented number of the decision-maker it agrees with in the current control cycle; otherwise, it sends a result rejection response message 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 either respond or refuse to respond. Responders receiving a result request respond to the decision-maker verified through a numbering rule: if the result request.N ≥ agreed.N, they send their initial flight control calculation result as the response content: (result.N, calculation result) forming a result-send response message to the decision-maker; otherwise, they send a result-rejection response message to the decision-maker. Based on the characteristics of auto-incrementing numbering, the decision-maker controls whether to send the initial flight control calculation result to the decision-maker who sent the result request by using the auto-incrementing number of the decision-maker they agree with. This ensures that the flight control calculation result is sent to as few decision-makers as possible, guaranteeing that only a unique decision-maker can generate a valid flight control calculation result.

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

[0137] The responder is used when there are two or more result requests. If the auto-incremented number of the decision-maker in the previous result request received by the responder is greater than or equal to the auto-incremented number of the decision-maker it agrees with in the current control cycle, the responder will send the obtained initial flight control calculation result as a result sending response message to the decision-maker corresponding to the previous result request. Otherwise, the responder will send a result rejection response message to the decision-maker in the previous result request.

[0138] If the auto-incremented number of the decision-maker in the subsequent result request received by the responder is less than the auto-incremented number of the decision-maker in the previous result request, then a result rejection response message is sent to the decision-maker corresponding to the subsequent result request.

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

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

[0141] In this case, the responder receives the previous result request before receiving the next result request.

[0142] Even if high-speed bus data messages are lost during the negotiation control process, the distributed negotiation control device can still operate normally through the negotiation and decision-making process. Even if multiple decision-makers appear during the negotiation phase, the initial flight control calculation result can be sent to the decision-maker who requests the result by using the auto-incrementing number of the decision-maker agreed upon by the decision-maker, based on the characteristics of the auto-incrementing number formation. This ensures that the flight control calculation result is sent to as few decision-makers as possible, and still achieves the goal of ensuring that the truly suitable decision-maker is selected according to the preset process during the decision-making phase. Only a unique decision-maker can form a flight control calculation result.

[0143] Preferably, the decision-maker: if the initial flight control calculation results received from the respondent are different, the calculation result is selected according to the majority rule, and when there are more than two different initial flight control calculation results, the two closest initial flight control calculation results are selected, and the arithmetic mean of the two closest flight control calculation results is used as the final flight control calculation result.

[0144] If the decision-maker receives initial flight control calculation results from more than half of the respondents, half means... Indicates to (After rounding down) the initial flight control calculation results of the responders, the decision-maker can summarize the received initial flight control calculation results, or, if no more than half of the responders send initial flight control calculation results, collect as many initial flight control calculation results as possible, and make a comprehensive judgment to determine the final flight control calculation result for this control cycle.

[0145] In conjunction with embodiments of the present invention, a space launch vehicle is also provided, including any of the aforementioned space flight control multi-CPU distributed negotiation control devices.

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

[0147] Each CPU node, serving as a computing and communication node, plays three roles: negotiator, decision-maker, and responder. Each CPU node can simultaneously assume multiple roles. Initially, during the negotiation phase, the CPU node acts as both a responder and a negotiator. In the control phase, the CPU node acts as both a decision-maker and a responder. CPU nodes that do not acquire decision-making power are merely responders, and decision-makers are also responders.

[0148] In this embodiment of the invention, multiple CPUs first negotiate within each control cycle to determine one CPU node as the decision-maker, which then issues the comprehensive control command (including comprehensive commands of multiple timing controls) for the current control cycle (e.g., each control cycle is 10ms). That is, in each control cycle, multiple CPUs need to negotiate to determine the decision-maker for each round, and this decision-maker ultimately issues the control command for that round. This enables synchronous and coordinated decision-making among multiple CPUs, ensuring that the initial calculation results of multiple (odd number) CPUs are ultimately unified into a single final flight control settlement result, which is then sent as the control result to the actuator to control the operation of the space launch vehicle.

[0149] Without relying on other hardware and systems on the rocket, it can form an effective control method at its own software and algorithm level, enabling multi-mode flight controllers to interact and compare to form control results. Even if one of the flight control computing nodes fails, the final flight control calculation result can still be obtained, achieving redundant control.

[0150] In a distributed system with K CPU nodes, a decision-maker can be identified in each calculation cycle to collect the initial flight control calculation results from all nodes and form the final flight control calculation result for issuing control commands. Because the number of CPU nodes is odd, and considering the decision-making principles for deterministic negotiation, a decision-maker emerges throughout the system. Even if (rounded down) CPU nodes malfunction, it can still work normally; if high-speed bus data packets are lost during the negotiation control process, it can still control the distributed negotiation control to run normally through the negotiation and decision-making process; even if there are multiple decision-makers in the negotiation phase, it can still achieve the goal of letting the truly appropriate decision-maker issue control commands according to the preset process in the decision-making phase.

[0151] It should be understood that the specific order or hierarchy of steps in the disclosed process 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 may be rearranged without departing from the scope of this disclosure. The appended method claims provide elements of various steps in an exemplary order and are not intended to limit the scope to the specific order or hierarchy described.

[0152] In the above detailed description, various features are combined together in a single embodiment to simplify this disclosure. This approach to disclosure should not be construed as reflecting an intention that embodiments of the claimed subject matter require more features than are explicitly stated in each claim. Rather, as reflected in the appended claims, the invention is presented with fewer features than all of the features of the single disclosed embodiment. Therefore, the appended claims are hereby explicitly incorporated into the detailed description, wherein each claim stands alone as a preferred embodiment of the invention.

[0153] The disclosed embodiments have been described above to enable any person skilled in the art to implement or use the present invention. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein can be applied to other embodiments without departing from the spirit and scope of this disclosure. Therefore, this disclosure is not limited to the embodiments given herein, but is consistent with the broadest scope of the principles and novel features disclosed in this application.

[0154] The foregoing description includes examples of one or more embodiments. It is certainly impossible to describe all possible combinations of components or methods in order to describe the above embodiments, but those skilled in the art will recognize that further combinations and arrangements of the various embodiments are possible. Therefore, the embodiments described herein are intended to cover all such changes, modifications, and variations that fall within the scope of the appended claims. Furthermore, the term "comprising" as used in the specification or claims is interpreted in a manner similar to the term "including," as interpreted when used as a conjunction in the claims. Additionally, the use of any term "or" in the specification of the claims is intended to mean "non-exclusive or."

[0155] Those skilled in the art will also understand 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 both. To clearly demonstrate the interchangeability of hardware and software, the functions of the various illustrative components, units, and steps described above have been generally described. Whether such functionality is implemented through hardware or software depends on the specific application and the overall system design requirements. Those skilled in the art can implement the described functions using various methods for each specific application, but such implementation should not be construed 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 this invention can be implemented or operate the described functions using a general-purpose processor, digital signal processor, application-specific integrated circuit (ASIC), 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; alternatively, it can be any conventional processor, controller, microcontroller, or state machine. The processor can also be implemented using a combination of computing devices, such as a digital signal processor and a microprocessor, multiple 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 this invention can be directly embedded in hardware, a software module executed by a processor, or a combination of both. The software module can be stored in RAM, flash memory, ROM, EPROM, EEPROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium in the art. Exemplarily, the storage medium can be connected to the processor so that the processor can read information from and write information to the storage medium. Optionally, the storage medium can also be integrated into the processor. The processor and storage medium can be housed in an ASIC, which can be housed in a user terminal. Optionally, the processor and storage medium can also be housed in different components of the user terminal.

[0158] In one or more exemplary designs, the functions described in the embodiments of the present invention can be implemented in hardware, software, firmware, or any combination of these three. If implemented in software, these functions can be stored on a computer-readable medium or transmitted on a computer-readable medium in the form of one or more instructions or code. Computer-readable media include computer storage media and communication media that facilitate the transfer of computer programs from one place to another. Storage media can be any available media that can be accessed by a general-purpose or special-purpose computer. For example, such computer-readable media can include, but is 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-purpose or special-purpose computer, or a general-purpose or special-purpose processor. Furthermore, any connection can be suitably 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 wirelessly, such as infrared, wireless and microwave, it is also included in the defined computer-readable medium. The disks and discs mentioned include compressed disks, laser discs, optical discs, DVDs, floppy disks, and Blu-ray discs. Disks typically copy data magnetically, while disks typically copy data optically using lasers. Combinations of the above can also be contained in computer-readable media.

[0159] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above description is only a specific embodiment 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 within 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: In each control cycle of the space launch vehicle's flight control, before processing various sensor data and / or the operational status information of the rocket body equipment, any available CPU node acts as a negotiator and negotiates with all CPU nodes via a high-speed bus to determine itself as 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 according to preset rules. If the negotiator receives no less than a preset number of negotiation agreement response messages, it confirms itself as the decision-maker for this control cycle. The number of CPU nodes is odd. Step 2: Each responder performs calculations based on the various sensor data and / or rocket body equipment operating status information collected during this control cycle to obtain its corresponding initial flight control calculation results. The responders are all CPU nodes. Step 3: The decision-maker sends a result request to all respondents to inquire about the initial flight control calculation results; Step 4: The respondent sends its corresponding initial flight control calculation result to the verified decision-maker; Step 5: The decision-maker determines the final flight control calculation result according to the received initial flight control calculation result and a preset rule, and sends the final flight control calculation result to the real-time bus. The final flight control calculation result is used to control the operation of the space launch vehicle. The aforementioned multi-CPU distributed negotiation control method for aerospace flight control also includes: Step 8: Assign a unique numerical identifier to each CPU node; Step 1 further includes: in each control cycle, each CPU node forms its own auto-incrementing number in the current control cycle based on the unique numerical number and the auto-incrementing number of the previous control cycle, wherein the initial value of the auto-incrementing number of each CPU node is its own unique numerical number. In step 1, each CPU node determines whether to agree to the negotiator as the decision-maker for this control cycle according to preset rules, specifically including: Any available CPU node acts as a negotiator and sends a negotiation request to all CPU nodes via the high-speed bus. The key of the negotiation request includes: a negotiation field and the negotiator's own auto-incrementing number. After receiving the negotiation request, each CPU node determines whether the auto-incrementing number of the negotiator in the negotiation request is greater than the auto-incrementing number of the decision-maker agreed by the CPU node in the previous control cycle. If the value is greater than the value, a negotiation agreement response message agreeing to the negotiation as the decision-maker is sent to the negotiation party, and the CPU node that sends the negotiation agreement response message records the auto-incrementing number of the decision-maker it agrees to; otherwise, a negotiation rejection response message rejecting the negotiation party as the decision-maker is sent to the negotiation party. If the number of consensus response messages received by the negotiator is not less than half the number of CPU nodes, then the negotiator determines itself as the decision-maker for this control cycle.

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 rocket body equipment operating status information from the real-time bus; Step 6 is executed in parallel with Step 1. Step 7: After the negotiator confirms itself as the decision-maker for this control cycle, the decision-maker notifies all CPU nodes on the real-time bus that it is the decision-maker for this control cycle.

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

4. 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 respondents to inquire about the initial flight control calculation results. The keywords of the result request include: the result field and the decision-maker's auto-incrementing number. Step 4 specifically includes: If the auto-incremented number of the decision-maker in the result request received by the responder is greater than or equal to the auto-incremented number of the decision-maker it agrees with in this control cycle, then the responder will send the obtained initial flight control calculation result as a result sending response message to the decision-maker corresponding to the result request; otherwise, a result rejection response message will be sent to the decision-maker corresponding to the result request.

5. The multi-CPU distributed negotiation control method for aerospace flight control according to claim 4, characterized in that, Step 3 also includes: If in step 1 there are two or more decision-makers, each decision-maker sends a result request to all respondents to inquire about the initial flight control calculation result; Step 4 specifically includes: When there are two or more result requests, if the auto-incremented number of the decision-maker in the previous result request received by the responder is greater than or equal to the auto-incremented number of the decision-maker it agrees with in the current control cycle, then the initial flight control calculation result obtained is formed into a result sending response message and sent to the decision-maker corresponding to the previous result request; otherwise, a result rejection response message is sent to the decision-maker in the previous result request. If the auto-incremented number of the decision-maker in the subsequent result request received by the responder is less than the auto-incremented number of the decision-maker in the previous result request, then a result rejection response message is sent to the decision-maker corresponding to the subsequent result request. If the auto-incremented number of the decision-maker in the subsequent result request received by the respondent is greater than the auto-incremented number of the decision-maker in the previous result request, and the auto-incremented number of the decision-maker in the subsequent result request is the auto-incremented number of the decision-maker agreed by the respondent, then a result sending response message is sent to the decision-maker corresponding to the subsequent result request, and the auto-incremented number of the negotiator agreed by the respondent is updated to the auto-incremented number of the decision-maker in the subsequent result request. If the auto-incremented number of the decision-maker in the subsequent result request received by the respondent is greater than the auto-incremented number of the decision-maker in the previous result request, and the auto-incremented number of the decision-maker in the subsequent result request is not the auto-incremented number of the decision-maker agreed upon by the respondent, then a result rejection response message is sent to the decision-maker corresponding to the subsequent result request. In this case, the responder receives the previous result request before receiving the next result request.

6. The multi-CPU distributed negotiation control method for aerospace flight control according to claim 1, characterized in that, Step 5 specifically includes: If the decision-maker receives different initial flight control calculation results from the respondent, the calculation result is selected according to the majority rule. When there are more than two different initial flight control calculation results, the two closest initial flight control calculation results are selected, and the arithmetic mean of the two closest flight control calculation results is used as the final flight control calculation result.

7. A multi-CPU distributed negotiation control device for aerospace flight control, characterized in that, include: The negotiation module is used for each control cycle of the flight control of the space launch vehicle. Before processing various sensor data and / or the operating status information of the rocket body equipment, any available CPU node acts as a negotiator and negotiates with all CPU nodes through a high-speed bus to determine itself as 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 according to preset rules. If the negotiator receives no less than a preset number of negotiation agreement response messages, it confirms itself as the decision-maker for this control cycle. The number of CPU nodes is odd. The responder is used to perform calculations based on the various sensor data and / or rocket body equipment operating status information collected in this control cycle to obtain their respective initial flight control calculation results. The responder is all CPU nodes. The decision-maker is used to send a result request to all respondents to inquire about the initial flight control calculation result; The responder is also used to send its corresponding initial flight control calculation result to the verified decision-maker; The decision-maker is also used to determine the final flight control calculation result according to the received initial flight control calculation result and a preset rule, and to send the final flight control calculation result to the real-time bus. The final flight control calculation result is used to control the operation of the space launch vehicle. The aforementioned multi-CPU distributed negotiation control device for aerospace flight control also includes: The numbering module is used to assign a unique numerical number to each CPU node when configuring it. The negotiation module is also used to form an auto-incrementing number for each CPU node in each control cycle based on the unique number and the auto-incrementing number of the previous control cycle, wherein the initial value of the auto-incrementing number of each CPU node is its own unique number. The negotiation module is specifically used for: any available CPU node to send a negotiation request to all CPU nodes via the high-speed bus, with the negotiation request keywords including: negotiation field and the negotiator's own auto-incrementing number; Respondent: Upon receiving the negotiation request, each CPU node, acting as a respondent, determines whether the auto-incrementing number of the negotiator in the negotiation request is greater than the auto-incrementing number of the decision-maker agreed upon by the CPU node in the previous control cycle. If it is greater, the CPU node sends a negotiation agreement response message to the negotiator, agreeing that the negotiator should be the decision-maker. The CPU node that sends the negotiation agreement response message records the auto-incrementing number of the decision-maker it has agreed upon. Otherwise, the CPU node sends a negotiation rejection response message to the negotiator, rejecting the negotiator from being the decision-maker. Decision maker: If the number of consensus response messages obtained is not less than half the number of CPU nodes, then the decision maker shall determine itself as the decision maker for this control cycle.

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

Images