A distributed collaborative control system for testing intelligent connected vehicles with low communication load

Abstract

This invention relates to the field of collaborative control testing technology, specifically a low-communication-load distributed collaborative control system for testing intelligent connected vehicles. The system includes a server and multiple computing nodes. The server constructs a centralized collaborative control model and a communication review model, and converts the centralized collaborative control model into a distributed collaborative control model. The distributed collaborative control model is decomposed into multiple collaborative control sub-models. Each collaborative control sub-model is assigned to a computing node. For each step of solving a collaborative control sub-model by a computing node, the solution result for that step is determined. The communication review model reviews the first auxiliary variable in the solution result and sends the reviewed first auxiliary variable to neighboring computing nodes, significantly reducing the communication load during the collaborative control process. When the preset conditions for ending the solution are met, the control command for that computing node is determined based on the solution result, completing the intelligent connected vehicle test.

Description

Technical Field

[0001] This specification relates to the field of collaborative control technology, and in particular to a distributed collaborative control system for testing intelligent connected vehicles with low communication load. Background Technology

[0002] With the rapid development of intelligent transportation systems, the functions of autonomous driving systems are evolving from single-vehicle intelligence to multi-vehicle cooperative driving based on vehicle-road cooperation. To fully verify the environmental perception, collaborative decision-making, and integrated control capabilities of vehicles in complex traffic flows, conducting large-scale multi-vehicle cooperative testing has become an indispensable and crucial step in the research and development and verification of intelligent connected vehicles.

[0003] Currently, methods for testing large-scale vehicle cooperative control can be mainly divided into two categories: centralized and distributed. The centralized method aggregates the state information of all vehicles under test in real time to a central controller, which performs unified modeling and optimization. Theoretically, this method can obtain the globally optimal solution for the system. However, in large-scale testing scenarios, this method faces significant bottlenecks: on the one hand, the testing system needs to maintain continuous, high-bandwidth data interaction between the central controller and all vehicles, resulting in extremely high communication load and imposing stringent requirements on network bandwidth and transmission reliability; on the other hand, the scale of solving the global optimization problem increases dramatically with the number of vehicles, putting enormous pressure on the computing power of the central controller and posing a single point of failure risk, threatening the robustness and security of the entire testing system.

[0004] To overcome the inherent limitations of centralized methods, distributed testing methods have emerged. In this architecture, each test vehicle acts as an independent computing node, communicating only locally with neighboring vehicles within a limited radius, and collaboratively completing control tasks through computation. However, existing distributed methods still face significant challenges in practical applications. Although the total communication volume is reduced compared to centralized methods, frequent exchange of optimization variables and intermediate results between computing nodes is still necessary during iterative problem-solving. This continuous and high-frequency communication interaction still generates a considerable amount of communication data. Under conditions of large test vehicle node scale or limited communication resources (e.g., channel congestion, insufficient bandwidth), significant communication delays can easily occur, thereby affecting the real-time response performance and closed-loop stability of the control system.

[0005] Therefore, this specification provides a distributed collaborative control system for testing intelligent connected vehicles with low communication load. Summary of the Invention

[0006] This specification provides a distributed collaborative control system for testing intelligent connected vehicles with low communication load, in order to partially solve the aforementioned problems existing in the prior art.

[0007] The following technical solution is adopted in this specification:

[0008] This specification provides a low-communication-load distributed collaborative control system for testing intelligent connected vehicles. The system includes a server and multiple computing nodes, where each computing node represents a different intelligent connected vehicle in the testing scenario.

[0009] The server is used to construct a centralized collaborative control model and a communication review model, and to convert the centralized collaborative control model into a distributed collaborative control model; the distributed collaborative control model is decomposed into multiple collaborative control sub-models using the alternating direction multiplier method; and the multiple collaborative control sub-models are distributed to each computing node respectively.

[0010] A computing node is used to solve the collaborative control sub-model allocated by the server. For each solution of the collaborative control sub-model by the computing node, the solution result of the computing node for that solution is determined. The communication review model is obtained, and the first auxiliary variable in the solution result is reviewed through the communication review model. The reviewed first auxiliary variable is sent to the preset neighbor computing nodes. When the preset condition for ending the solution is met, the control command of the computing node is determined according to the solution result of the last solution of the collaborative control sub-model by the computing node. The computing node then performs collaborative control with other computing nodes in the intelligent connected vehicle test scenario according to the control command to complete the intelligent connected vehicle test.

[0011] Based on the aforementioned technical means, in the intelligent connected vehicle testing scenario, this solution does not broadcast all intermediate results to surrounding computing nodes when solving the cooperative control problem. By reviewing the model, invalid, erroneous, or minimally changing intermediate results (i.e., the first auxiliary variable) can be filtered out, significantly reducing network bandwidth consumption and the processing load on neighboring computing nodes. Furthermore, each computing node ultimately generates local control commands based on its final solution result. These commands are generated under the constraints of the global model and the influence of neighbor information, thus achieving overall coordination (i.e., cooperative control in intelligent connected vehicle testing) without a central scheduler or similar equipment. This solution enables distributed solution of cooperative control for large-scale intelligent connected vehicles in intelligent connected vehicle testing scenarios, significantly improving the efficiency of solving cooperative control problems. Simultaneously, by dynamically filtering redundant communication data through communication review, it significantly reduces the communication load during the cooperative control process and the communication resource requirements of the cooperative control equipment, enhancing the system's scalability in large-scale intelligent connected vehicle testing scenarios.

[0012] Furthermore, the centralized collaborative control model constructed by the server is characterized by the following expression:

[0013]

[0014] The constraints of the centralized collaborative control model are:

[0015]

[0016]

[0017]

[0018] in, , represents the set of indices for compute nodes. To calculate the number of nodes, To compute node i (i∈[1, ..., ...) The index function of ]) To compute the state vector of node i, Let i be the control vector for computing node i; To compute the state equation for node i; and These are the upper and lower bounds of the state vector, respectively. and These are the upper and lower bounds of the control vector, respectively; Obstacle avoidance constraints between computing node i and computing node j; For computational nodes with obstacle avoidance relationships A set of indexed pairs.

[0019] Furthermore, the server is used to introduce initial auxiliary variables to convert the centralized collaborative control model into a distributed collaborative control model;

[0020] The expression for the distributed collaborative control model is:

[0021]

[0022]

[0023]

[0024] The constraints of the distributed collaborative control model are:

[0025]

[0026] in, The first auxiliary variable introduced corresponds to each computing node. The second auxiliary variables introduced correspond to each computing node; It is a set of state vectors; The computational nodes in the constraints of the centralized collaborative control model The state equations, the upper and lower bounds of the state vector, and the indicator functions corresponding to the upper and lower bounds of the control vector; This is the indicator function corresponding to the obstacle avoidance constraint between computation node i and computation node j.

[0027] Furthermore, the expression for the communication censorship model constructed by the server is:

[0028]

[0029] in, To determine the number of iterations for solving the cooperative control sub-model, we define the number of solutions required to solve the cooperative control sub-model. For computing nodes In the The filtering threshold function value is obtained when solving the cooperative control sub-model. For computing nodes The first auxiliary variable most recently sent to the neighboring compute node The value; For computing node i The first auxiliary variable in solving the cooperative control sub-model The value; For the preset non-negative decreasing filter threshold sequence, the first... Each filtering threshold.

[0030] Based on the aforementioned technical means, in the standard process of the Alternating Direction Method of Multipliers (ADMM), each iteration requires all computing nodes to broadcast their latest data. In scenarios with dense traffic, a massive amount of periodic communication will occur. Therefore, an "event-triggered" communication model is implemented, where communication is triggered only when the state estimate of a computing node (vehicle) changes significantly. As the cooperative control problem approaches convergence, the solutions of each computing node tend to stabilize with minimal changes, leading to a sharp decrease in communication frequency and significantly saving valuable wireless channel bandwidth. Furthermore, through a designed non-negative decreasing filtering threshold sequence, the value of τ is relatively large in the early stages of iteration, allowing computing nodes to communicate only when their states undergo significant adjustments. This avoids resource waste caused by frequent communication during the initial exploration phase. In the later stages of iteration, the value of τ becomes smaller, forcing computing nodes to perform more refined coordination and more frequent information synchronization (even though the changes themselves are small at this point) as they approach the optimal solution. This ultimately ensures that the algorithm converges to a high-precision solution, rather than remaining at a coarse approximation.

[0031] Furthermore, the server is used to update the distributed collaborative control model based on the communication review model;

[0032] The updated expression for the distributed cooperative control model is:

[0033]

[0034] The updated constraints of the distributed cooperative control model are as follows:

[0035] .

[0036] Furthermore, the server is used to introduce augmented Lagrange multipliers and a quadratic penalty term to convert the updated distributed cooperative control model into an augmented Lagrange function; determine initialization parameters, including an initial set of state vectors, an initial set of control vectors, an initial set of first auxiliary variables, an initial set of augmented Lagrange multiplier values, and coefficients of the quadratic penalty term; based on the initialization parameters, the augmented Lagrange function is split into multiple cooperative control sub-models, including multiple first cooperative control sub-models and one second cooperative control sub-model, the number of the multiple first cooperative control sub-models being consistent with the number of computing nodes; the multiple first cooperative control sub-models are respectively allocated to each computing node, and the second cooperative control sub-model is allocated to computing nodes whose computing resources have reached a preset threshold;

[0037] The expressions for the augmented Lagrangian function, the first sub-model of cooperative control, and the second sub-model of cooperative control are respectively:

[0038]

[0039]

[0040]

[0041]

[0042] in, For the augmented Lagrange multipliers; ; ; is the coefficient of the quadratic penalty term.

[0043] Furthermore, the computing node is used to determine the state vector of each solution after solving the cooperative control sub-model, and send the state vector of the solution to the preset neighbor computing node; determine the first auxiliary variable after the solution; review the first auxiliary variable after the solution through the communication review model; determine whether the first auxiliary variable after the solution passes the review. If yes, it is stored and sent to the neighbor computing node. If no, it is discarded and the first auxiliary variable most recently sent to the neighbor computing node is used as the first auxiliary variable after the solution.

[0044] The expression for the first auxiliary variable after this solution is determined as follows:

[0045]

[0046] in, This is a preset connection matrix.

[0047] Furthermore, the computation nodes are used to update the values ​​of the augmented Lagrange multipliers after this solution;

[0048] The updated expression for the values ​​of the augmented Lagrange multipliers is as follows:

[0049]

[0050] .

[0051] Furthermore, the computing node is used to calculate the original residual and the dual residual after the current solution; determine whether the original residual has reached the preset original residual convergence value and whether the dual residual has reached the preset dual residual convergence value; if both are yes, then the solution of the cooperative control sub-model ends, the control vector obtained in this solution is determined, and the control command of the computing node itself is determined according to the control vector obtained in this solution; if either is no, then the solution of the cooperative control sub-model continues.

[0052] Furthermore, the state vector can be a six-dimensional column vector representing the longitudinal position, lateral position, vehicle speed, heading angle, lateral velocity, and yaw rate of the computing node; the control vector can be a three-dimensional column vector representing the longitudinal acceleration command, front wheel steering angle command, and yaw moment of the computing node.

[0053] The above-mentioned technical solutions adopted in this specification can achieve the following beneficial effects:

[0054] In this solution for intelligent connected vehicle testing scenarios, each computing node (intelligent connected vehicle) does not broadcast all intermediate results to surrounding computing nodes when solving the cooperative control problem. By reviewing the model, invalid, erroneous, or minimally changing intermediate results (i.e., the first auxiliary variable) can be filtered out, significantly reducing network bandwidth consumption and the processing load on neighboring computing nodes. Furthermore, each computing node ultimately generates local control commands based on its final solution result. These commands are generated under the constraints of the global model and influenced by neighbor information, thus achieving overall coordination (i.e., cooperative control in intelligent connected vehicle testing) without a central scheduler or similar equipment. This solution enables distributed solution of cooperative control for large-scale intelligent connected vehicles in testing scenarios, significantly improving the efficiency of solving cooperative control problems. Simultaneously, by dynamically filtering redundant communication data through communication review, it significantly reduces the communication load and communication resource requirements of cooperative control equipment during the cooperative control process, enhancing the system's scalability in large-scale intelligent connected vehicle testing scenarios. Attached Figure Description

[0055] The accompanying drawings, which are included to provide a further understanding of this specification and form part of this specification, illustrate exemplary embodiments and are used to explain this specification, but do not constitute an undue limitation thereof. In the drawings:

[0056] Figure 1 A schematic diagram of a low-communication-load distributed collaborative control system for testing intelligent connected vehicles, provided as an embodiment of this specification;

[0057] Figure 2 This document provides a flowchart of a distributed collaborative control method for testing intelligent connected vehicles with low communication load.

[0058] Figure 3 This document provides a flowchart of a distributed collaborative control method for testing intelligent connected vehicles with low communication load.

[0059] Figure 4 This specification provides a corresponding Figure 2 and Figure 3 A schematic diagram of the structure of an electronic device. Detailed Implementation

[0060] To make the objectives, technical solutions, and advantages of this specification clearer, the technical solutions of this specification will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this specification, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments in this specification without creative effort are within the scope of protection of this application.

[0061] In embodiments of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0062] In large-scale vehicle cooperative control testing, existing distributed testing schemes have not been deeply optimized in terms of "communication load suppression" during the testing process. Their communication modes often carry a large amount of non-critical or redundant information, failing to achieve fine-grained scheduling and intelligent utilization of communication resources. This restricts the applicability and efficiency of the method in ultra-large-scale, resource-constrained testing scenarios.

[0063] Therefore, this specification provides a distributed collaborative control system for testing intelligent connected vehicles with low communication load to solve the above problems.

[0064] The technical solutions provided in the various embodiments of this specification are described in detail below with reference to the accompanying drawings.

[0065] Figure 1 This specification provides a schematic diagram of a low-communication-load distributed collaborative control system for testing intelligent connected vehicles, as illustrated in the embodiments. The system (hereinafter referred to as the collaborative control system) includes a server and multiple computing nodes, which represent multiple intelligent connected vehicles in the testing scenario. In this specification, the computing nodes can be intelligent connected vehicles with data processing capabilities. The server can communicate with each intelligent connected vehicle in the collaborative control scenario (indicated by dashed double-headed arrows). Each intelligent connected vehicle can process data through devices such as an onboard electronic control unit (ECU). The intelligent connected vehicles can also communicate with each other.

[0066] In one or more embodiments of this specification, at the start of intelligent connected vehicle testing, the server can be used to construct a centralized collaborative control model and a communication review model, and convert the centralized collaborative control model into a distributed collaborative control model. Then, using the alternating direction multiplier method, the distributed collaborative control model is decomposed into multiple collaborative control sub-models. These multiple collaborative control sub-models are then distributed to various computing nodes.

[0067] Subsequently, due to the existence of multiple computing nodes, each computing node receives and solves the collaborative control sub-model sent by the server. Therefore, taking one computing node as an example, after receiving the collaborative control sub-model assigned by the server, this computing node solves the collaborative control sub-model. For each solution of the collaborative control sub-model by this computing node, the solution result for that computing node is determined. Then, the communication review model is obtained from the server, and in accordance with a preset communication review strategy, the first auxiliary variable in the solution result is reviewed through the communication review model. The reviewed first auxiliary variable is then sent to preset neighboring computing nodes, which can be computing nodes within a preset range around this computing node. Finally, when the preset conditions for ending the solution of the collaborative control sub-model are met, the control command for this computing node is determined based on the solution result of the last solution of the collaborative control sub-model, and the control command is executed. In the intelligent connected vehicle test scenario, collaborative control with other computing nodes is achieved, completing the intelligent connected vehicle test.

[0068] In one or more embodiments of this specification, the expression for the centralized collaborative control model constructed by the server is:

[0069]

[0070] The constraints of this centralized collaborative control model are:

[0071]

[0072]

[0073]

[0074] in, This represents the set of indexes for computing nodes, i.e., the set of indexes for intelligent connected vehicles. This indicates the first vehicle (referred to as Vehicle 1) set up in the intelligent connected vehicle test scenario, and so on. The expression equals "number" to indicate the nth vehicle (or simply vehicle) in the intelligent connected vehicle test scenario. ). To calculate the number of nodes, which is also the number of intelligent connected vehicles. To compute node (vehicle) i (i∈[1, ..., ...), The index function can be set as a scalar function, such as a quadratic form or a linear combination, etc. This specification does not impose any restrictions; it can be set according to the actual situation. To compute the state vector of node i, Let i be the control vector for computing node i. Let be the state equation for calculating node i, be a local constraint that only involves itself, be a constraint that each vehicle must follow its own physical motion laws, and be a vehicle dynamics constraint. and These are the upper and lower bounds of the state vector, respectively. and These are the upper and lower bounds of the control vector, respectively. The obstacle avoidance constraint between computing node i and computing node j usually represents the distance between computing node i and computing node j minus a safety threshold. ≥0 means that the two vehicles represented by computing node i and computing node j must maintain a safe distance. For computational nodes with obstacle avoidance relationships The set of indexed pairs defines which vehicles have this obstacle avoidance relationship.

[0075] It is worth noting that the state vector It can be a six-dimensional column vector representing the longitudinal position, lateral position, vehicle speed, heading angle, lateral velocity, and yaw rate of computation node i. Control vector It can be a three-dimensional column vector representing the longitudinal acceleration command, front wheel steering angle command, and yaw moment of calculation node i. Therefore, vehicle data such as longitudinal position, lateral position, vehicle speed, heading angle, lateral velocity, yaw rate, longitudinal acceleration, front wheel steering angle, and yaw moment must be maintained within a certain physical range and cannot exceed physical limits or safety regulations. Thus, upper and lower bounds of the state vector and the control vector are set as constraints.

[0076] Furthermore, each intelligent connected vehicle in the collaborative control scenario can be equipped with communication devices, positioning devices, computing units, and execution units. The communication devices can obtain vehicle information (such as longitudinal position, lateral position, speed, heading angle, lateral velocity, yaw rate, longitudinal acceleration, front wheel steering angle, and yaw moment) from the vehicle's CAN bus. When it is necessary to broadcast information to neighboring vehicles, it can send this information to surrounding vehicles via vehicle-to-vehicle (V2V) communication and can also receive information sent by surrounding vehicles, forming an information exchange. The positioning devices can obtain the vehicle's current longitudinal position, lateral position, speed, and other data through devices such as the Global Positioning System (GPS) and send it to the CAN bus. The computing unit obtains information about its own vehicle and surrounding vehicles from the CAN bus, calculates the collaborative control sub-model, and sends the determined control commands to the execution unit. The execution unit executes the control commands to achieve collaborative control.

[0077] In one or more embodiments of this specification, the server may further introduce initial auxiliary variables to convert the centralized collaborative control model into a distributed collaborative control model.

[0078] The expression for the distributed cooperative control model is:

[0079]

[0080]

[0081]

[0082] The constraints of the distributed cooperative control model are:

[0083]

[0084] To transform the centralized cooperative control model into a distributed cooperative control model, it is necessary to decouple the vehicles by introducing two sets of auxiliary variables. The first auxiliary variable introduced corresponds to each computing node. These are the second auxiliary variables introduced, corresponding to each computation node. Among them, It can be viewed as the corresponding computing node state vector A copy, It can also be viewed as a computing node. state vector Another copy used for obstacle avoidance constraints. And, despite the introduction of the second auxiliary variable... It is introduced as an auxiliary vector, but is also considered part of the state vector, therefore, This is a set of state vectors. Furthermore, the constraints of the distributed cooperative control model mean the original state vectors. and its second auxiliary variable They must all be equal to the same first auxiliary variable. In other words, through To coordinate and This ensures that they remain consistent.

[0085] Then, the server can incorporate the constraints into the distributed cooperative control model using indicator functions. Two exponential functions are defined, namely... and . The computational nodes in the constraints of the centralized collaborative control model The state equations, upper and lower bounds of the state vectors, and the indicator functions corresponding to the upper and lower bounds of the control vectors, if they satisfy the computation node... If the constraints, such as the state equation, upper and lower bounds of the state vector, and upper and lower bounds of the control vector, are met, the cost is 0; otherwise, it is infinite, which is equivalent to forcibly satisfying the constraints. As for obstacle avoidance constraints between vehicles... This is the indicator function corresponding to the obstacle avoidance constraint between computing node i and computing node j. If the obstacle avoidance constraint is satisfied, the cost is 0; otherwise, it is infinite, and the obstacle avoidance constraint may be forced to be satisfied.

[0086] In one or more embodiments of this specification, the expression for the communication censorship model constructed by the server is:

[0087]

[0088] in, To solve for the number of iterations of the cooperative control sub-model, we define the number of times the cooperative control sub-model needs to be solved. For computing nodes In the The filtering threshold function value is obtained when solving the cooperative control sub-model. For computing nodes The first auxiliary variable most recently sent to the neighboring compute node The value of . For computing node i The first auxiliary variable in solving the cooperative control sub-model The value of . Let Frobenius be the Frobenius norm of both. For the preset non-negative decreasing filter threshold sequence, the first... There are several filtering thresholds, meaning that in a non-negative decreasing sequence of filtering thresholds... The value increases with the number of iterations. The non-negative decreasing filter threshold sequence can be in the form of an exponential function, a power function, etc. For example, if an exponential function is chosen, its form can be: , The preset initial sequence threshold, This is the attenuation factor, which can be taken as a value such as 0.96.

[0089] When using a communication censorship model to examine the first auxiliary variable, a possible censorship strategy is to calculate... ,when At that time, the vehicle (i.e., update compute node i) Otherwise, the vehicle maintain .

[0090] In one or more embodiments of this specification, the server may further update the distributed collaborative control model based on the communication review model and with reference to the review strategy of the first auxiliary variable.

[0091] The updated expression for the distributed cooperative control model is:

[0092]

[0093] Furthermore, due to the introduction of the process of reviewing the first auxiliary variable, compute node i sends to its neighboring compute nodes... At that time, what is sent is not necessarily the result calculated in each iteration. Instead, it was after review. Therefore, the constraints of the updated distributed cooperative control model are:

[0094]

[0095] Furthermore, in one or more embodiments of this specification, the server is also used to introduce augmented Lagrange multipliers. The updated distributed cooperative control model is transformed into an augmented Lagrangian function using a quadratic penalty term. Furthermore, the server determines the initialization parameters, including the initial set of state vectors. Initial control vector set Initial set of first auxiliary variables Augmented Lagrange multiplier initial value set coefficient of the second penalty term The server then, based on the initial parameters, decomposes the augmented Lagrangian function into multiple cooperative control sub-models. These cooperative control sub-models include multiple cooperative control first sub-models and one cooperative control second sub-model. The number of cooperative control first sub-models is consistent with the number of computing nodes. Finally, these cooperative control first sub-models are allocated to each computing node, meaning each computing node is assigned one cooperative control first sub-model with the same index. The cooperative control second sub-model is allocated to computing nodes whose computing resources have reached a preset threshold (i.e., computing nodes with available computing resources to solve the cooperative control second sub-model).

[0096] The expressions for the augmented Lagrangian function, the first sub-model of cooperative control, and the second sub-model of cooperative control are as follows:

[0097]

[0098]

[0099]

[0100]

[0101] in, To augment the Lagrange multipliers. . . This refers to the coefficient of the quadratic penalty term. Among the initialized parameters is the initial state vector set. Indicates initialization Each subsequent iteration increments the index of the top-right corner by 1. Similarly, the initial control vector set... Initial set of first auxiliary variables Augmented Lagrange multiplier initial value set All cases can be referenced from the state vector set. .

[0102] It is worth noting that the last term in the augmented Lagrange function... This is a constant term. During the iterative solution process, the constant term can be omitted without affecting the solution result.

[0103] In one or more embodiments of this specification, a computing node is used to solve the cooperative control sub-model after receiving it. If the computing node receives a first cooperative control sub-model and a second cooperative control sub-model, it performs multiple iterative solutions on each of these sub-models. Furthermore, after each solution of the cooperative control sub-model, the state vector of that solution is determined and sent to a preset neighboring computing node. Then, the first auxiliary variable after that solution is determined. The first auxiliary variable after that solution is reviewed through communication review model.

[0104] Next, it is determined whether the first auxiliary variable after this solution passes the review. If yes, the first auxiliary variable after this solution is stored and sent to the neighboring computing nodes. If not, the first auxiliary variable after this solution is discarded, and the first auxiliary variable most recently sent to the neighboring computing nodes is used as the first auxiliary variable after this solution. Referring to the above review strategy, the filtering threshold function value after each iteration can be calculated. If the filtering threshold function value is greater than 0, the review passes; otherwise, it fails.

[0105] Furthermore, the computation nodes are also used to update the values ​​of the augmented Lagrange multipliers after this solution.

[0106] The expression for the first auxiliary variable after this solution is determined as follows:

[0107]

[0108] This is a preset connection matrix.

[0109] The updated expression for the values ​​of the augmented Lagrange multipliers is as follows:

[0110]

[0111]

[0112] Furthermore, a method to determine whether the preset conditions for ending the solution have been met after this solution can be that the computation nodes calculate the original residuals after this solution. With dual residual Determine whether the original residuals have reached the preset original residual convergence value ( And whether the dual residual reaches the preset dual residual convergence value ( ) If all are yes, then the solution to the cooperative control sub-model ends, the control vector obtained in this solution is determined, and the control command for the computing node itself is determined based on the control vector obtained in this solution. If any is no, then the solution to the cooperative control sub-model continues.

[0113] Of course, in this specification, another method for determining whether the preset conditions for ending the solution have been met after this solution is to determine the number of times the computing node has solved the cooperative control sub-model, i.e., the number of iterations, after this solution. Then, determine whether this number of iterations has reached the preset maximum number of iterations. If yes, then end the solution of the cooperative control sub-model, determine the control vector obtained in this solution, and determine the computing node's own control command based on the control vector obtained in this solution. If not, continue solving the cooperative control sub-model. It is worth noting that with each solution, the computing node can obtain the state vector and control vector, as well as auxiliary variables, for that solution.

[0114] In this specification, all bolded letters represent vector forms. Furthermore, the computation nodes in this specification can represent not only intelligent connected vehicles, but also devices such as drones, and are not limited to these in this specification.

[0115] This specification provides a table of some parameters involved in solving the cooperative control sub-model using computing nodes, as shown in Table 1 below.

[0116] Table 1 Iteration Parameter Table

[0117]

[0118] In summary, based on Figure 1 This paper presents a low-communication-load distributed collaborative control system for intelligent connected vehicle testing. In intelligent connected vehicle testing scenarios, each computing node (intelligent connected vehicle) does not broadcast all intermediate results to surrounding computing nodes when solving collaborative control problems. By reviewing the model, invalid, erroneous, or minimally changing intermediate results (i.e., the first auxiliary variable) can be filtered out, significantly reducing network bandwidth consumption and the processing load on neighboring computing nodes. Furthermore, each computing node ultimately generates local control commands based on its final solution. These commands are generated under the constraints of the global model and the influence of neighbor information, thus achieving overall collaboration (i.e., collaborative control in intelligent connected vehicle testing) without a central scheduler or similar equipment. This solution enables distributed solution of collaborative control for large-scale intelligent connected vehicles in intelligent connected vehicle testing scenarios, significantly improving the efficiency of solving collaborative control problems. Simultaneously, by dynamically filtering redundant communication data through communication review, it significantly reduces the communication load during collaborative control and the communication resource requirements of collaborative control equipment, enhancing the system's scalability in large-scale intelligent connected vehicle testing scenarios.

[0119] Figure 2 This specification provides a flowchart of a low-communication-load distributed collaborative control method for testing intelligent connected vehicles. The method is applied to a server in a low-communication-load distributed collaborative control system for testing intelligent connected vehicles, and includes:

[0120] S200: Construct a centralized collaborative control model and a communication review model, and convert the centralized collaborative control model into a distributed collaborative control model.

[0121] In one or more embodiments of this specification, the server may construct a centralized collaborative control model and a communication review model, and convert the centralized collaborative control model into a distributed collaborative control model.

[0122] S202: The distributed cooperative control model is decomposed into multiple cooperative control sub-models by using the alternating direction multiplier method.

[0123] In one or more embodiments of this specification, the server decomposes the distributed cooperative control model into multiple cooperative control sub-models using the alternating direction multiplier method.

[0124] S204: Distribute the multiple collaborative control sub-models to each computing node.

[0125] In one or more embodiments of this specification, the server distributes multiple collaborative control sub-models to each computing node.

[0126] The contents of steps S200 to S204 above can be found in the contents of the above system, and will not be repeated here.

[0127] based on Figure 2 The low-communication-load distributed collaborative control method for testing intelligent connected vehicles shown can realize distributed solution in collaborative control scenarios of large-scale intelligent connected vehicles, which can significantly improve the solution efficiency of collaborative control problems. At the same time, the construction of communication review can dynamically filter redundant communication data, thereby significantly reducing the communication load and communication resource requirements of collaborative control equipment in the collaborative control process, and enhancing the scalability of the system in large-scale collaborative control scenarios.

[0128] Figure 3 This specification provides a flowchart of a low-communication-load distributed cooperative control method for testing intelligent connected vehicles. The method is applied to computing nodes in a low-communication-load distributed cooperative control system for testing intelligent connected vehicles, and includes:

[0129] S300: Solve the cooperative control sub-model for server allocation.

[0130] In one or more embodiments of this specification, a computing node can solve the cooperative control sub-model allocated by the server and determine the solution result.

[0131] S302: For each solution of the collaborative control sub-model for this computing node, determine the solution result of this computing node for that solution.

[0132] In one or more embodiments of this specification, a computing node can determine the solution result for each time it solves the cooperative control sub-model.

[0133] S304: Obtain the communication review model, review the first auxiliary variable in the solution result through the communication review model, and send the reviewed first auxiliary variable to the preset neighbor computing node.

[0134] In one or more embodiments of this specification, a computing node may obtain a communication review model constructed by a server, review the first auxiliary variable in the solution result through the communication review model, and send the reviewed first auxiliary variable to a preset neighbor computing node.

[0135] S306: When the preset conditions for ending the solution are met, the control command of the computing node is determined based on the solution result of the last solution of the cooperative control sub-model of the computing node, and the computing node performs cooperative control with other computing nodes in the intelligent connected vehicle test scenario according to the control command to complete the intelligent connected vehicle test.

[0136] In one or more embodiments of this specification, when a preset condition for ending the solution is met, the control command for the computing node is determined based on the solution result of the last solution of the cooperative control sub-model. Then, according to the control command, the computing node can perform cooperative control with other computing nodes in the intelligent connected vehicle test scenario to complete the intelligent connected vehicle test.

[0137] The contents of steps S300 to S306 above can be found in the contents of the above system, and will not be repeated here.

[0138] based on Figure 3The illustrated low-communication-load distributed collaborative control method for intelligent connected vehicle testing addresses this issue. In intelligent connected vehicle testing scenarios, each computing node (the intelligent connected vehicle) does not broadcast all intermediate results to surrounding computing nodes when solving the collaborative control problem. By reviewing the model, invalid, erroneous, or minimally changing intermediate results (i.e., the first auxiliary variable) are filtered out, significantly reducing network bandwidth consumption and the processing load on neighboring computing nodes. Furthermore, each computing node ultimately generates local control commands based on its final solution. These commands are generated under the constraints of the global model and influenced by neighbor information, thus achieving overall collaboration (i.e., collaborative control in intelligent connected vehicle testing) without a central scheduler or similar equipment. This scheme enables distributed solution of collaborative control for large-scale intelligent connected vehicles in testing scenarios, significantly improving the efficiency of solving collaborative control problems. Simultaneously, by dynamically filtering redundant communication data through communication review, it significantly reduces the communication load during collaborative control and the communication resource requirements of collaborative control equipment, enhancing the system's scalability in large-scale intelligent connected vehicle testing scenarios.

[0139] This specification also provides a computer-readable storage medium storing a computer program that can be used to execute the above-described... Figure 2 and Figure 3 This paper presents a distributed collaborative control method for testing intelligent connected vehicles with low communication load.

[0140] This instruction manual also provides Figure 4 The diagram shows a schematic structural representation of the electronic device. Figure 4 As shown, at the hardware level, this electronic device includes a processor, internal bus, network interface, memory, and non-volatile memory, and may also include other hardware required for business operations. The processor reads the corresponding computer program from the non-volatile memory into memory and then runs it to achieve the above. Figure 2 and Figure 3 This paper presents a distributed collaborative control method for testing intelligent connected vehicles with low communication load.

[0141] Of course, in addition to software implementation, this specification does not exclude other implementation methods, such as logic devices or a combination of hardware and software. In other words, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0142] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must also be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0143] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0144] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0145] For ease of description, the above devices are described in terms of function, divided into various units. Of course, in implementing this specification, the functions of each unit can be implemented in one or more software and / or hardware components.

[0146] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0147] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0148] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0149] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0150] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0151] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0152] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic or disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0153] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0154] Those skilled in the art will understand that the embodiments of this specification can be provided as methods, systems, or computer program products. Therefore, this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this specification may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0155] This specification can be described in the general context of computer-executable instructions that are executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a specific task or implement a specific abstract data type. This specification can also be practiced in distributed computing environments, where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0156] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0157] The above description is merely an embodiment of this specification and is not intended to limit this specification. Various modifications and variations can be made to this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims of this specification.

Claims

1. An intelligent networked vehicle test low communication load distributed cooperative control system, characterized in that, The system includes a server and multiple computing nodes, where the multiple computing nodes represent multiple intelligent connected vehicles in an intelligent connected vehicle test scenario, wherein: The server is used to construct a centralized collaborative control model and a communication review model, and to convert the centralized collaborative control model into a distributed collaborative control model; the distributed collaborative control model is decomposed into multiple collaborative control sub-models using the alternating direction multiplier method; and the multiple collaborative control sub-models are distributed to each computing node respectively. A computing node is used to solve the collaborative control sub-model allocated by the server. For each solution of the collaborative control sub-model by the computing node, the solution result of the computing node for that solution is determined. The communication review model is obtained, and the first auxiliary variable in the solution result is reviewed through the communication review model. The reviewed first auxiliary variable is sent to the preset neighbor computing nodes. When the preset condition for ending the solution is met, the control command of the computing node is determined according to the solution result of the last solution of the collaborative control sub-model by the computing node. The computing node then performs collaborative control with other computing nodes in the intelligent connected vehicle test scenario according to the control command to complete the intelligent connected vehicle test. 2.The intelligent connected vehicle test low communication load distributed cooperative control system of claim 1, wherein, The expression for the centralized collaborative control model constructed by the server is: The constraints of the centralized collaborative control model are: in, , represents the set of indices for compute nodes. To calculate the number of nodes, To compute node i (i∈[1, ..., ...) The index function of ]) To compute the state vector of node i, Let i be the control vector for computing node i; To compute the state equation for node i; and These are the upper and lower bounds of the state vector, respectively. and These are the upper and lower bounds of the control vector, respectively; Obstacle avoidance constraints between computing node i and computing node j; For computational nodes with obstacle avoidance relationships A set of indexed pairs.

3. The intelligent connected vehicle testing low-communication-load distributed collaborative control system as described in claim 2, characterized in that, The server is used to introduce initial auxiliary variables and convert the centralized collaborative control model into a distributed collaborative control model. The expression for the distributed collaborative control model is: The constraints of the distributed collaborative control model are: in, The first auxiliary variable introduced corresponds to each computing node. The second auxiliary variables introduced correspond to each computing node; It is a set of state vectors; The computational nodes in the constraints of the centralized collaborative control model The state equations, the upper and lower bounds of the state vector, and the indicator functions corresponding to the upper and lower bounds of the control vector; This is the indicator function corresponding to the obstacle avoidance constraint between computation node i and computation node j.

4. The intelligent connected vehicle testing low-communication-load distributed collaborative control system as described in claim 3, characterized in that, The expression for the communication censorship model constructed by the server is: in, To determine the number of iterations for solving the cooperative control sub-model, we define the number of solutions required to solve the cooperative control sub-model. For computing nodes In the The filtering threshold function value is obtained when solving the cooperative control sub-model. For computing nodes The first auxiliary variable most recently sent to the neighboring compute node The value; For computing node i The first auxiliary variable in solving the cooperative control sub-model The value; For the preset non-negative decreasing filter threshold sequence, the first... Each filtering threshold.

5. The intelligent connected vehicle testing low-communication-load distributed collaborative control system as described in claim 4, characterized in that, A server is used to update the distributed collaborative control model based on the communication review model; The updated expression for the distributed cooperative control model is: The updated constraints of the distributed cooperative control model are as follows: 。 6. The intelligent connected vehicle testing low-communication-load distributed collaborative control system as described in claim 5, characterized in that, The server is used to introduce augmented Lagrange multipliers and a quadratic penalty term to convert the updated distributed cooperative control model into an augmented Lagrange function; determine initialization parameters, including an initial set of state vectors, an initial set of control vectors, an initial set of first auxiliary variables, an initial set of augmented Lagrange multiplier values, and coefficients of the quadratic penalty term; based on the initialization parameters, decompose the augmented Lagrange function into multiple cooperative control sub-models, including multiple first cooperative control sub-models and one second cooperative control sub-model, the number of first cooperative control sub-models being consistent with the number of computing nodes; allocate the multiple first cooperative control sub-models to each computing node, and allocate the second cooperative control sub-model to computing nodes whose computing resources have reached a preset threshold; The expressions for the augmented Lagrangian function, the first sub-model of cooperative control, and the second sub-model of cooperative control are respectively: in, For the augmented Lagrange multipliers; ; ; is the coefficient of the quadratic penalty term.

7. The intelligent connected vehicle testing low-communication-load distributed collaborative control system as described in claim 6, characterized in that, The computing node is used to determine the state vector of each solution after solving the cooperative control sub-model, and send the state vector of the solution to the preset neighbor computing node; determine the first auxiliary variable after the solution; review the first auxiliary variable after the solution through the communication review model; determine whether the first auxiliary variable after the solution passes the review. If yes, it is stored and sent to the neighbor computing node. If no, it is discarded and the first auxiliary variable most recently sent to the neighbor computing node is used as the first auxiliary variable after the solution. The expression for the first auxiliary variable after this solution is determined as follows: in, This is a preset connection matrix.

8. The intelligent connected vehicle testing low-communication-load distributed collaborative control system as described in claim 7, characterized in that, Compute nodes are used to update the values ​​of the augmented Lagrange multipliers after this solution; The updated expression for the values ​​of the augmented Lagrange multipliers is as follows: 。 9. The intelligent connected vehicle testing low-communication-load distributed collaborative control system as described in claim 8, characterized in that, The computation node is used to calculate the original residual and the dual residual after the current solution; it determines whether the original residual has reached the preset original residual convergence value and whether the dual residual has reached the preset dual residual convergence value; if both are yes, the solution of the cooperative control sub-model ends, the control vector obtained in this solution is determined, and the control command of the computation node itself is determined according to the control vector obtained in this solution; if either is no, the solution of the cooperative control sub-model continues.

10. A distributed collaborative control system for low communication load in intelligent connected vehicle testing as described in claim 2, characterized in that, The state vector can be a six-dimensional column vector representing the longitudinal position, lateral position, vehicle speed, heading angle, lateral velocity, and yaw rate of the computing node; the control vector can be a three-dimensional column vector representing the longitudinal acceleration command, front wheel steering angle command, and yaw moment of the computing node.

Images