A Trusted Collaborative Control Method and System for Vehicle Queues Based on Blockchain

Abstract

This invention relates to a blockchain-based trusted collaborative control method and system for vehicle platoons, belonging to the field of intelligent connected transportation technology. The method includes steps such as vehicle state perception and data broadcasting, RSU node data verification and blockchain uploading, vehicle comprehensive trust value calculation and updating, predictive control compensation mechanism, abnormal behavior detection and malicious node isolation, and dynamic optimization and adjustment of the platoon structure. The system executes this method, ensuring data consistency and immutability through blockchain technology to enhance information security; utilizing trust value calculation and anomaly detection mechanisms to guarantee platoon security; and dynamically adjusting the platooning order based on priority scoring to improve collaborative control performance. This invention achieves high security, high real-time performance, and high robustness in collaborative vehicle platoon control under complex conditions, and has significant application value.

Description

Technical Field

[0001] This invention belongs to the field of intelligent connected transportation technology and relates to a blockchain-based trusted collaborative control method and system for vehicle queuing. Background Technology

[0002] In recent years, with the rapid development of intelligent connected vehicle technology and autonomous driving technology, vehicle platoon cooperative control has received widespread attention as an important means to improve traffic flow efficiency, reduce energy consumption, and ensure driving safety. Through V2V and V2I communication, vehicles in a platoon can share location, speed, acceleration, and other driving intention information in real time, enabling cooperative decision-making and control. Existing vehicle cooperative control methods mainly rely on centralized or semi-centralized information exchange models. For example, traditional cooperative adaptive cruise control utilizes direct communication information from the vehicle ahead and local sensor information to achieve longitudinal following control. Existing vehicle platoon control employs a distributed control strategy based on information from multiple preceding vehicles to enhance platoon stability.

[0003] However, the current control strategy has the following shortcomings:

[0004] 1. Insufficient data credibility

[0005] V2V / V2X communication is open and lacks a centralized authentication mechanism, which means that transmitted information may be tampered with, forged, or delayed. Especially in complex traffic environments, attackers can disrupt the stability of queue control by forging critical data such as location and speed, and even trigger a chain collision.

[0006] 2. Difficulty in identifying malicious nodes

[0007] Traditional methods have limited ability to detect abnormal node behavior and rely on consistency detection based on local observations. However, they are difficult to accurately identify malicious nodes with covert attack behaviors (such as gradual camouflage attacks and coordinated deception attacks) in a short period of time, which increases the vulnerability of the system.

[0008] 3. Lack of a unified and reliable data synchronization mechanism

[0009] Due to the lack of chain-based anti-tampering protection, traditional synchronization relies on "recent information priority" or timestamp sorting. However, when faced with replay attacks and delay attacks, it cannot ensure the timeliness and consistency of information, affecting the accuracy of collaborative control decisions.

[0010] 4. The real-time performance of control commands is limited by communication latency.

[0011] In complex environments (such as highways and urban canyons), V2V link latency and packet loss are common, causing damage to the control loop. Introducing protective mechanisms (such as redundancy verification and encrypted authentication) further exacerbates communication latency, leading to vehicle control lag, severely impacting platoon coordination performance, and even disrupting queue stability.

[0012] 5. Blockchain applications are limited by real-time requirements.

[0013] Although blockchain technology has become a potential solution to improve system security due to its decentralized, tamper-proof, and traceable characteristics, existing general-purpose blockchain systems (such as Bitcoin and Ethereum) have problems such as long data verification and synchronization cycles and large delays, making them unsuitable for direct application in vehicle collaborative control scenarios with extremely high real-time requirements.

[0014] In summary, the existing solutions have the following shortcomings:

[0015] First, traditional V2X communication data lacks effective anti-tampering and traceability mechanisms, making it vulnerable to forgery, tampering, and replay attacks. This leads to vehicle decisions being based on untrusted information, posing serious security risks. Second, existing collaborative control systems generally do not fully consider the impact of communication delays on real-time control, resulting in delayed control responses and reduced stability and security of vehicle platooning. Third, traditional methods lack dynamic trust management and malicious node protection mechanisms. When some nodes send false or abnormal information, the system struggles to identify and isolate them in a timely manner, easily causing the entire queue to fail. Furthermore, existing queue structure adjustments are mostly static or preset, lacking the ability to dynamically optimize queue arrangement based on vehicle trustworthiness, resulting in insufficient platooning robustness. Summary of the Invention

[0016] In view of this, the purpose of this invention is to provide a blockchain-based trusted collaborative control method and system for vehicle queues. In terms of overall architecture design, it systematically improves the reliability and intelligence level of queue collaborative control from multiple levels such as perception, authentication, data synchronization, control compensation, security protection and structural optimization.

[0017] To achieve the above objectives, the present invention provides the following technical solution:

[0018] A blockchain-based trusted collaborative control method for vehicle queuing, the method comprising:

[0019] The vehicle performs its own state perception, signs the state perception data, and then broadcasts the data.

[0020] After each RSU node receives the broadcast data packet from the vehicle, it first verifies the data, then dynamically divides all RSU nodes into several groups, and after reaching a consensus on a new block within the group, it uploads the data to the blockchain.

[0021] After the data is uploaded to the blockchain, a comprehensive trust value for the vehicle is calculated by combining the vehicle's direct and indirect trust, and the calculated comprehensive trust value is updated on the blockchain.

[0022] Establish a predictive control compensation mechanism based on trust-weighted fusion to compensate for communication delays during blockchain synchronization, and output the compensated control commands to the vehicle;

[0023] Continuously detect abnormal behavior and isolate malicious nodes;

[0024] The queue structure is dynamically optimized and adjusted based on vehicle priority scores, and optimization instructions are broadcast to vehicles via a blockchain network.

[0025] Furthermore, firstly, during the vehicle's self-state perception process, each vehicle periodically collects its own motion state data, including: position coordinates (x, y), velocity v, acceleration a, and driving intention (Intent); then, the collected self-motion state data is processed into standardized data packets:

[0026] msg=<VehicleID,(x,y),v,a,Intent,Timestamp>

[0027] The Timestamp is used to mark the time when the data was generated;

[0028] Then, the vehicle uses its own private key SK. V The process of performing a digital signature on a data packet is as follows:

[0029] Hash the original data packet msg to generate a digest:

[0030] h = Hash(msg)

[0031] Where Hash(·) represents the hash operation;

[0032] Using the vehicle's private key SK V Encrypt the digest h to generate the digital signature Sign:

[0033] Sign = Encrypt(SK) V ,h)

[0034] Where Encrypt(·) is the encryption operation;

[0035] The final broadcast message contains the original data and a signature field:

[0036] msg_signed=<msg,Sign>

[0037] The vehicle broadcasts msg_signed to nearby RSU nodes within its coverage area via the V2X communication interface.

[0038] Furthermore, the RSU node first performs digital signature verification on the received vehicle-side broadcast data packets and retains the data packets that pass the verification; at the same time, it checks the integrity and format of the data fields and removes abnormal or corrupted data.

[0039] Then, based on the number and quality of vehicle messages received and verified within the period, the interaction volume score PoI_Score is calculated:

[0040]

[0041] Among them, PoI_Score j I represents the interaction score of the j-th node. valid (i) represents the verification result marker for the i-th message, where I valid (i) = 1 indicates that it is valid, I valid (i) = 0 indicates invalidity; N j W represents the total number of information items for the j-th node. i This represents the importance weight of the i-th message;

[0042] Then, the RSU nodes are dynamically divided into several groups based on their geographical distribution, traffic density, and PoI scores.

[0043] Within each group, the RSU node with the highest interaction score is selected as the temporary leader. The temporary leader generates a new block proposal, which contains the vehicle status data cached in this period. All RSU nodes in the group broadcast and verify the proposed block. If the verification is successful, the group enters the confirmation phase. After a preset proportion of nodes in the group have completed the confirmation, the nodes broadcast messages and lock the new block, thus achieving consensus within the group.

[0044] Finally, cross-group synchronization and global ledger updates are performed. Each group synchronizes the new block digests formed by local consensus across groups, and the edge server aggregates the consensus results of all shards.

[0045] Furthermore, the grouping process for RSU nodes is as follows:

[0046] 1) Initial screening based on geographical proximity: Prioritize grouping physically adjacent RSU nodes into the same group;

[0047] 2) Based on traffic density normalization balance: Set a load limit for each target group; if the traffic density of a certain area exceeds the density threshold, split it into multiple subgroups, or move some RSUs into the low-density area group.

[0048] 3) Sorting and grading based on PoI score: All RSU nodes are sorted from high to low according to their PoI_Score values. A preset proportion of high-scoring nodes are given priority to be assigned as candidate Leader nodes in the group; medium-scoring nodes are used as consensus nodes; nodes with too low scores or those that are currently fully loaded are set as read-only nodes or only perform synchronization tasks and do not participate in consensus for the time being.

[0049] 4) Ultimately, several groups are formed that satisfy geographical continuity, traffic load balance, and capacity differentiation.

[0050] Furthermore, the calculation process for the vehicle's overall trust value is as follows:

[0051] First, calculate the vehicle's direct trust score. The vehicle's direct trust score is related to the spatial consistency, temporal consistency, and historical behavior of the vehicle's broadcast data, and is expressed as follows:

[0052] T direct =ω+e -λ(c+t+m)

[0053] Where c represents the spatial consistency index, which reflects the error between the location reported by the vehicle and the actual physical location of the neighboring vehicle; t represents the temporal consistency index, which reflects the broadcast delay of vehicle data; m represents the historical trust decay factor, which reflects the impact of long-term accumulated dishonesty; ω represents the basic trust bias value, which prevents excessively low trust in the early stage; and λ represents the exponential decay coefficient, which controls the sensitivity of abnormal behavior to the decline in trust value.

[0054] Then, the indirect trust score of the vehicle is calculated. Indirect trust infers the reliability of the target vehicle through feedback from neighboring vehicles. Bayesian inference is used to fuse evidence from neighboring vehicles to calculate the indirect trust value.

[0055]

[0056] Where q(e) represents the prior probability that the target vehicle behaves normally; ed n q(ed) represents the evidence provided by the nth neighboring vehicle; Ξ represents the set of neighbors supporting the normal behavior of the target vehicle; NΞ represents the set of neighbors supporting the abnormal behavior of the target vehicle; n |e) indicates evidence observed under normal behavior. n The probability of; This indicates that evidence was observed under anomalous behavior. n The probability of.

[0057] Then, direct trust and indirect trust are weighted and fused to calculate the final comprehensive vehicle trust value T. V :

[0058] T V =αT direct +βTindirect

[0059] Where α and β represent the weighting coefficients of direct trust and indirect trust, respectively, αβ=1, and α>β;

[0060] After each comprehensive trust value calculation is completed, the RSU node will assign the vehicle's corresponding T... V The trust value change record is updated on the chain and appended to the vehicle block data in the form of a transaction.

[0061] Furthermore, the compensation process of the trust-weighted fusion-based predictive control compensation mechanism is as follows:

[0062] First, the on-chain synchronization information is aggregated, and the vehicle periodically synchronizes the status information and timestamps of several vehicles ahead of it from the on-chain. s And select and adopt the trust value T. V Higher than the set threshold θ T Vehicle data;

[0063] The system then performs weighted fusion of vehicle state data with different levels of confidence. For example, it assumes that vehicle i receives data from the set of neighboring vehicles. The estimated reference state is obtained by weighting and averaging the synchronized data.

[0064]

[0065] Where a j v j and x j Let these represent the acceleration, velocity, and position state of the adjacent vehicle j, respectively. This indicates the corresponding trust value. and These represent the information received by vehicle i from the set of neighboring vehicles. The synchronous data is weighted and averaged to obtain the estimated reference position, velocity, and acceleration state of the neighboring vehicle j;

[0066] Then, based on the estimated reference state, the vehicle constructs a state prediction for the next τ steps and defines state variables. The discrete model of vehicle dynamics is as follows:

[0067]

[0068] Where A, B, and C represent time-varying coefficient matrices, u(k) represents control commands, ω(k) and v(k) represent system disturbances and measurement noise, and y(k) represents the observable output of the vehicle system at time k;

[0069] The predicted state identifier for the next τ steps is:

[0070]

[0071] The vehicle calculates the control error based on the error between its current predicted state and the estimated reference state:

[0072]

[0073] in,

[0074] Finally, a predictive compensation controller is designed using the feedback gain matrix K:

[0075] u(k)=-Ke(k)

[0076] K is dynamically obtained using a gain scheduling mechanism; the control instruction u(k) is bound to a timestamp t. s The output is sent to the vehicle execution layer to achieve vehicle control.

[0077] Furthermore, during the continuous detection of abnormal behavior and isolation of malicious nodes, firstly, the deviation between the predicted trajectory and the actual trajectory is detected. Within each cycle, the vehicle end predicts the future τ-step state of the neighboring vehicles based on the neighboring vehicle states synchronized on the chain. At the same time, the actual broadcast status y of the neighboring vehicle j is received via V2X. j (k+τ), calculate the deviation between the two trajectories:

[0078]

[0079] The weighted sum of all deviations within a time window is defined as the anomaly score E for vehicle j. j :

[0080]

[0081] Where n represents the number of observation steps within the detection period, γ k The weighting coefficient for time step k;

[0082] Set an abnormal threshold θ E If the anomaly score of vehicle j satisfies:

[0083] E j >θ E

[0084] If vehicle j is found to be exhibiting abnormal behavior, it will be immediately isolated. Simultaneously, an isolation notice will be issued on-chain via a smart contract, marking vehicle j as an "untrusted node," updating the on-chain state, and lowering vehicle j's trust value. To the lowest level.

[0085] Furthermore, during the dynamic optimization and adjustment of the queue structure, the vehicles in the queue are first given a priority score. iThe calculation, and the priority function, are defined as follows:

[0086]

[0087] Where, d i d represents the distance from vehicle i to the leader vehicle in the queue; max R represents the maximum length of the queue when it is stable. i T represents the historical reliability score of vehicle i. Vi α1 represents the trust value of vehicle i; α2 and α3 represent the weight coefficients of each factor, and α1+α2+α3=1;

[0088] When an abnormal vehicle appears, the system will determine the priority of each vehicle. i The values ​​are sorted, and higher-priority vehicles are placed in key positions, lower-priority vehicles are placed at the end of the queue, and abnormal vehicles are removed from the queue.

[0089] Furthermore, the optimized and adjusted queue reorganization scheme is generated by the RSU node, and the optimization instructions of the reorganization scheme are broadcast to each vehicle through the blockchain. The optimization instructions include: new platooning order, new target position for each vehicle, update of car-following reference object, safe distance and adjustment of car-following strategy parameters;

[0090] After receiving the reorganization and optimization instruction, each vehicle autonomously adjusts its queue position according to a unified safety swapping protocol, and a new queue is formed under the control of the controller.

[0091] On the other hand, a system for implementing the aforementioned blockchain-based trusted collaborative control method for vehicle platooning is also proposed. This system includes a vehicle-side blockchain light node client, a predictive control compensation module, a dynamic trust management module, an anomaly detection module, several roadside units (RSUs), and an edge server. The vehicle-side blockchain light node client is deployed in the vehicle, and the vehicle communicates with the RSUs via a V2X communication module. The roadside units are connected to the edge server.

[0092] The vehicle-side blockchain light node client performs its own state awareness, signs the state awareness data, and then broadcasts the data.

[0093] Roadside Units (RSUs) verify data and upload it to the blockchain using a consensus algorithm.

[0094] After the data is uploaded to the blockchain, the dynamic trust management module calculates the vehicle's comprehensive trust value by combining the vehicle's direct and indirect trust, and updates the calculated comprehensive trust value on the blockchain.

[0095] The predictive control compensation module establishes a trust-weighted fusion-based predictive control compensation mechanism to compensate for communication delays during blockchain synchronization and outputs the compensated control commands to the vehicle.

[0096] The anomaly detection module continuously detects abnormal behavior and isolates malicious nodes;

[0097] Ultimately, the roadside unit (RSU) dynamically optimizes and adjusts the vehicle priority scoring queue structure, and broadcasts the optimization instructions to each vehicle via the blockchain network.

[0098] The beneficial effects of this invention are as follows:

[0099] (1) The present invention ensures the consistency and immutability of vehicle status data across multiple nodes, fundamentally improving the information security and synchronization reliability of the system.

[0100] (2) This invention ensures that malicious nodes can be accurately identified and eliminated in the early stages, thus guaranteeing the overall security and robustness of the queue and overcoming the problem of weak protection against attacks and abnormal behavior in traditional systems.

[0101] (3) Based on the comprehensive priority scoring function, the formation order of vehicles in the fleet is dynamically adjusted, which realizes the priority deployment of high-trust and high-reliability vehicles in key positions, effectively improving the overall collaborative control performance and anti-interference ability of the fleet, and avoiding the shortcomings of the traditional static formation method in complex traffic environment.

[0102] Through the above-mentioned technological innovations, this invention can achieve high security, high real-time performance and high robustness of vehicle platoon collaborative control under complex conditions such as communication delays, untrusted nodes and dynamic environmental changes, significantly improving the overall efficiency and safety level of intelligent connected transportation systems, and has important application promotion value and industrialization prospects.

[0103] Other advantages, objectives, and features of the invention will be set forth in part in the description which follows, and in part will be apparent to those skilled in the art from the following examination, or may be learned from practice of the invention. The objectives and other advantages of the invention can be realized and obtained through the following description. Attached Figure Description

[0104] To make the objectives, technical solutions, and advantages of the present invention clearer, the preferred embodiments of the present invention will be described in detail below with reference to the accompanying drawings, wherein:

[0105] Figure 1 This is a schematic diagram of the overall process of the blockchain-based trusted collaborative control method for vehicle queuing according to an embodiment of the present invention;

[0106] Figure 2 This is a detailed process diagram of the blockchain-based trusted collaborative control method for vehicle queuing according to an embodiment of the present invention;

[0107] Figure 3 This is a schematic diagram of the data uploading process according to an embodiment of the present invention;

[0108] Figure 4 This is a flowchart illustrating the anomaly detection and queue optimization process according to an embodiment of the present invention. Detailed Implementation

[0109] The following specific examples illustrate the implementation of the present invention. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and various details in this specification can be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of the present invention. Unless otherwise specified, the following embodiments and features can be combined with each other.

[0110] The accompanying drawings are for illustrative purposes only and are schematic diagrams, not actual pictures. They should not be construed as limiting the invention. To better illustrate the embodiments of the invention, some parts in the drawings may be omitted, enlarged, or reduced, and do not represent the actual product dimensions. It is understandable to those skilled in the art that some well-known structures and their descriptions may be omitted in the drawings.

[0111] In the accompanying drawings of the embodiments of the present invention, the same or similar reference numerals correspond to the same or similar components. In the description of the present invention, it should be understood that if terms such as "upper," "lower," "left," "right," "front," and "rear" indicate the orientation or positional relationship based on the orientation or positional relationship shown in the drawings, they are only for the convenience of describing the present invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, the terms used to describe positional relationships in the drawings are only for illustrative purposes and should not be construed as limiting the present invention. For those skilled in the art, the specific meaning of the above terms can be understood according to the specific circumstances.

[0112] Please see Figures 1-4 This is a trusted collaborative control method and system for vehicle queuing based on blockchain.

[0113] Example 1

[0114] In this embodiment, the blockchain-based trusted collaborative control method for vehicle queues includes the following parts: vehicle status perception and signature data broadcasting, data verification, consensus and blockchain on-chaining, dynamic trust value calculation and updating, predictive control compensation and instruction generation, abnormal behavior detection and malicious node isolation, and dynamic optimization and adjustment of queue structure.

[0115] Specifically, such as Figure 1 As shown, the detailed process is as follows:

[0116] 1) The vehicle performs its own state perception, signs the state perception data, and then broadcasts the data:

[0117] Each vehicle periodically collects its own motion state data, including: position coordinates (x, y), velocity v, acceleration a, and driving intention (such as cruise control, lane change, braking, etc.). This information is then used to generate standardized data packets.

[0118] msg=<VehicleID,(x,y),v,a,Intent,Timestamp>

[0119] The Timestamp is used to mark the time when the data was generated, preventing replay attacks.

[0120] To ensure the credibility and integrity of the data source, the vehicle uses its own private key SK. V The process of performing a digital signature on a data packet is as follows: First, hash the original data packet msg to generate a digest:

[0121] h = Hash(msg)

[0122] Where Hash(·) represents the hash operation;

[0123] Then use the vehicle's private key SK V Encrypt the digest h to generate the digital signature Sign:

[0124] Sign = Encrypt(SK) V ,h)

[0125] Where Encrypt(·) is the encryption operation;

[0126] The final broadcast message contains the original data and a signature field:

[0127] msg_signed=<msg,Sign>

[0128] The vehicle broadcasts msg_signed to nearby RSU nodes within its coverage area via the V2X communication interface. Upon receiving the message, the RSU nodes will verify the authenticity of the message source and the integrity of the data using a signature verification mechanism.

[0129] 2) After receiving the broadcast data packet from the vehicle, each RSU node first verifies the data, then dynamically divides all RSU nodes into several groups, and uploads the new block to the blockchain after reaching consensus within the group:

[0130] After receiving data packets broadcast by vehicles, the RSU nodes first perform data preprocessing and preliminary verification. This includes digital signature verification of the data packets to ensure their authenticity, and checking the integrity and format of data fields, discarding any abnormal or corrupted data. Next, they calculate the Proof of Interaction (PoI) score. Each RSU node calculates its PoI score based on the quantity and quality of vehicle messages it received and verified within the period.

[0131]

[0132] Among them, PoI_Score j I represents the interaction score of the j-th node. valid (i) represents the verification result flag of the i-th message (1 for valid, 0 for invalid), N j W represents the total number of information items for the j-th node. i This represents the importance weight of the i-th message (e.g., giving higher weight to an emergency braking intent). RSU nodes with higher scores have higher proposal and voting rights in subsequent consensus processes.

[0133] Then, based on the geographical distribution, traffic density, and PoI score of RSU nodes, the RSU nodes are dynamically divided into several groups (Shards): 1) Initial screening based on geographical proximity: Physically adjacent RSU nodes are prioritized to be grouped into the same group to avoid cross-regional communication delays. 2) Traffic density normalization and balancing: A load cap is set for each target group; if the traffic density of a certain area is high, it is split into multiple subgroups, or some RSUs are moved to low-density area groups. 3) Sorting and grading based on PoI score: All RSU nodes are sorted from high to low according to their PoI value, and the top 30% of high-scoring nodes are prioritized as candidate Leader nodes within the group; nodes with medium scores are used as consensus nodes; nodes with too low a score or whose current load is full are set as read-only nodes or only perform synchronization tasks and do not participate in consensus. 4) Finally, several groups that meet the requirements of geographical continuity, traffic load balancing, and capacity differentiation are formed.

[0134] Each shard executes an independent consensus process, improving processing concurrency and reducing synchronization latency. Within each shard, consensus is reached, and the RSU node with the highest PoI score becomes the temporary leader, generating a new block proposal containing cached vehicle status data for the current period. All RSU nodes in the group broadcast and verify the proposed block; if verification passes, it enters the Prepare confirmation phase. After more than 2 / 3 of the nodes have completed Prepare confirmation, the nodes broadcast a Commit message and lock the new block, achieving group consensus. Finally, cross-group synchronization and global ledger updates are performed. Each shard synchronizes the block digests formed by local consensus across groups, and edge servers aggregate the consensus results of all shards to ensure global ledger consistency. Successfully agreed-upon data is officially uploaded to the blockchain, becoming part of the system's trusted synchronization.

[0135] 3) After the data is uploaded to the blockchain, a comprehensive trust value for the vehicle is calculated by combining direct and indirect trust, and the calculated comprehensive trust value is updated on the blockchain:

[0136] To combat forged data and malicious nodes, a dynamic trust management mechanism is introduced on-chain. First, a direct trust evaluation is performed, reflecting the consistency and reliability of the vehicle's historical behavior. In each evaluation cycle, the system scores the vehicle based on the spatial consistency, temporal consistency, and historical behavior records of its broadcast data. The direct trust score formula is as follows:

[0137] T direct =ω+e -λ(c+t+m)

[0138] Wherein, c represents the spatial consistency index, which reflects the error between the location reported by the vehicle and the actual physical location of the neighboring vehicle; t represents the temporal consistency index, which reflects the broadcast delay of vehicle data; m represents the historical trust decay factor, which reflects the impact of long-term accumulated dishonesty; ω represents the basic trust bias value, which prevents excessively low trust in the early stage; and λ represents the exponential decay coefficient, which controls the sensitivity of abnormal behavior to the decline in trust value.

[0139] Next is the indirect trust evaluation, which infers the reliability of the target vehicle through feedback from neighboring vehicles; the indirect trust value is calculated by fusing evidence from neighboring vehicles using Bayesian inference.

[0140]

[0141] Where q(e) represents the prior probability that the target vehicle behaves normally; ed n q(ed) represents the evidence provided by the nth neighboring vehicle; Ξ represents the set of neighbors supporting the normal behavior of the target vehicle; NΞ represents the set of neighbors supporting the abnormal behavior of the target vehicle; n |e) indicates evidence observed under normal behavior.n The probability of; This indicates that evidence was observed under anomalous behavior. n The probability of this is determined by cross-validation of neighboring vehicle feedback based on on-chain synchronization information, avoiding direct reliance on nodes with low trust. Then, direct and indirect trust are weighted and fused to calculate the final comprehensive vehicle trust value T. V :

[0142] T V =αT direct +βT indirect

[0143] Here, α and β represent the weighting coefficients of direct trust and indirect trust, respectively. α+β=1, and α>β, to prevent the influence of collective deception by neighbors.

[0144] After each comprehensive trust value calculation is completed, the RSU node will assign the vehicle's corresponding T... V Updated on the blockchain, the trust value change record is attached to the vehicle block data in the form of a transaction, supporting historical traceability and auditing.

[0145] Finally, the trust value is applied to the vehicle platoon cooperative control decision-making process. When each vehicle shares state information, it is based on its trust value T. V Dynamic weighting is applied, prioritizing information from high-trust vehicles and reducing the influence coefficient of information from low-trust vehicles. When vehicle T... V Below the set threshold θ T This triggers the anomaly detection and isolation process.

[0146] 4) Establish a trust-weighted fusion-based predictive control compensation mechanism to compensate for communication delays during blockchain synchronization, and output the compensated control commands to the vehicle;

[0147] To compensate for communication latency during blockchain synchronization and to fully utilize high-trust vehicle information to improve control decision quality, a predictive control compensation mechanism based on trust-weighted fusion is designed. First, on-chain synchronization information is aggregated, and the vehicle periodically synchronizes the status information and timestamps t of several vehicles ahead of it from the blockchain. s And select and adopt the trust value T. V Higher than the set threshold θ T The vehicle data is then weighted and fused based on vehicle status data of different confidence levels. Assume vehicle i receives data from the neighboring vehicle set... The estimated reference state is obtained by weighting and averaging the synchronized data.

[0148]

[0149] Where a j v j and x jLet these represent the acceleration, velocity, and position state of the adjacent vehicle j, respectively. This indicates the corresponding trust value.

[0150] Based on the estimated reference state, the vehicle constructs a state prediction for the next τ steps and defines state variables. The discrete model of vehicle dynamics is as follows:

[0151]

[0152] Where A, B, and C represent the system time-varying coefficient matrix, u(k) represents the control input, ω(k) and v(k) represent the system disturbance and measurement noise, and y(k) represents the observable output of the vehicle system at time k.

[0153] Therefore, the formula for predicting the state at the next τ steps is as follows:

[0154]

[0155] The vehicle calculates the control error based on the error between its current predicted state and the estimated reference state:

[0156]

[0157] in The error e(k) can be refined into distance error, speed error and acceleration error according to different control objectives and scenarios, so as to realize scenarios such as longitudinal queuing control, lateral lane change or merging control.

[0158] Finally, a predictive compensation controller is designed using the feedback gain matrix K:

[0159] u(k)=-Ke(k)

[0160] K can be dynamically obtained using a gain scheduling mechanism. The control instruction u(k) is bound to a timestamp t. s The output is sent to the vehicle execution layer to achieve vehicle control.

[0161] 5) Continuously detect abnormal behavior and isolate malicious nodes:

[0162] To ensure the robustness and security of the queue system, malicious nodes are identified and isolated. First, the deviation between the predicted trajectory and the actual trajectory is detected. Within each cycle, the vehicle-side predicts the future state of neighboring vehicles in step τ based on the synchronized states of neighboring vehicles on the blockchain. At the same time, the actual broadcast status y of the neighboring vehicle j is received via V2X. j (k+τ), calculate the deviation between the two trajectories:

[0163]

[0164] To accumulate and quantify the degree of anomaly of vehicle j, an anomaly score E is defined. j The weighted cumulative sum of all deviations within a certain time window:

[0165]

[0166] Where n represents the number of observation steps within the detection period, γ k This represents the weighting coefficient for time step k.

[0167] Set an abnormal threshold θ E If the anomaly score of vehicle j satisfies:

[0168] E j >θ E

[0169] If vehicle j exhibits abnormal behavior, the system immediately implements isolation measures, issuing an isolation notice on-chain via a smart contract, marking vehicle j as an "untrusted node," updating the on-chain state, and lowering the trust value of vehicle j. Reduced to the lowest level. The queue re-executes control decisions and formation optimizations based on high-trust vehicles.

[0170] 6) Dynamically optimize and adjust the queue structure based on vehicle priority scores:

[0171] Prioritize vehicles in the fleet i The calculation, and the priority function, are defined as follows:

[0172]

[0173] Where, d i d represents the distance from vehicle i to the leader vehicle in the queue; max R represents the maximum length of the queue when it is stable. i α1 represents the historical reliability score of vehicle i; α2 and α3 represent the weight coefficients of each factor, and α1+α2+α3=1.

[0174] When an abnormal vehicle appears, the system will determine the priority of each vehicle. i The system sorts vehicles by priority, placing higher-priority vehicles in key positions, lower-priority vehicles at the end of the queue, and removing extremely low-trust and abnormal vehicles from the queue, maintaining a loosely coordinated approach to avoid affecting the overall queue security.

[0175] The reorganization plan is generated by the RSU node. Optimization instructions are broadcast via the blockchain network, including: a new platooning order; new target positions for each vehicle; updates to the car-following reference object (change in the preceding vehicle ID); and adjustments to safe following distance and car-following strategy parameters.

[0176] After receiving the reorganization command, each vehicle autonomously adjusts its queue position according to a unified safety repositioning protocol (such as lane changing and acceleration / deceleration control), and a new queue is formed under the control of the controller.

[0177] Connections and functions of each part:

[0178] Vehicle Status Awareness and Signature Data Broadcast: Provides vehicle status data and ensures the reliability of the data.

[0179] Data verification and consensus mechanism: RSU nodes verify data and upload it to the blockchain through a consensus algorithm to ensure data synchronization and consistency.

[0180] Dynamic Trust Management: Evaluate and update the trust value of vehicles to determine their influence in queue control.

[0181] Predictive control compensation: Based on the prediction of vehicle status and trust-weighted information, precise control commands are generated.

[0182] Abnormal behavior detection and malicious node isolation: Abnormal behavior is detected by monitoring trajectory deviations to ensure the security of the queue.

[0183] Queue structure optimization: Adjust the queue according to vehicle priority and trust value to ensure efficient and safe vehicle platooning.

[0184] Example 2

[0185] This embodiment proposes a system for executing the aforementioned blockchain-based trusted collaborative control method for vehicle queuing. The system includes a vehicle-side blockchain light node client, a predictive control compensation module, a dynamic trust management module, an anomaly detection module, several roadside units (RSUs), and an edge server. The vehicle-side blockchain light node client is deployed in the vehicle, and the vehicle communicates with the RSUs via a V2X communication module. The roadside units are connected to the edge server.

[0186] The vehicle-side blockchain light node client performs its own state awareness, signs the state awareness data, and then broadcasts the data.

[0187] Roadside Units (RSUs) verify data and upload it to the blockchain using a consensus algorithm.

[0188] After the data is uploaded to the blockchain, the dynamic trust management module calculates the vehicle's comprehensive trust value by combining the vehicle's direct and indirect trust, and updates the calculated comprehensive trust value on the blockchain.

[0189] The predictive control compensation module establishes a trust-weighted fusion-based predictive control compensation mechanism to compensate for communication delays during blockchain synchronization and outputs the compensated control commands to the vehicle.

[0190] The anomaly detection module continuously detects abnormal behavior and isolates malicious nodes;

[0191] Ultimately, the roadside unit (RSU) dynamically optimizes and adjusts the vehicle priority scoring queue structure, and broadcasts the optimization instructions to each vehicle via the blockchain network.

[0192] like Figure 2 As shown, this embodiment uses a convoy of 7 vehicles on a smart highway as an example. The vehicles are numbered V1 (lead vehicle), V2, V3, V4 (relay key node), V5, V6, and V7 (following vehicles). All vehicles are equipped with a V2X communication module; a vehicle-side blockchain lightweight node client; a predictive control compensation module; and a dynamic trust management and anomaly detection module. A roadside unit (RSU) is deployed every 500 meters along the highway, connecting to the edge server to form a local lightweight distributed ledger system. Specific process:

[0193] 1. Vehicle status perception and signature data broadcasting:

[0194] Each vehicle periodically (every 100ms) senses its own motion status, including: position coordinates (x, y), speed v, acceleration a, and driving intention (such as cruise, lane change, braking, etc.). The vehicle broadcasts msg_signed to nearby RSU nodes within its coverage area via V2X.

[0195] 2. Data verification, consensus, and blockchain on-chain processing:

[0196] Data upload flowchart as follows Figure 3 As shown, RSU nodes perform the following operations: verify digital signatures to ensure the authenticity of the data source; check data format and field integrity; qualified data enters the cache pool, and each RSU is dynamically grouped (Sharding) according to its interaction score. Within each Shard, consensus is achieved: the RSU with the highest PoI score becomes the temporary Leader, which is confirmed by Prepare. After more than 2 / 3 of the nodes have completed Prepare confirmation, the node broadcasts a Commit message and locks the new block, achieving consensus within the group. The new block digest is synchronized across groups, the edge server summarizes the ledger, and a network-wide consistency update is completed, officially putting the vehicle status data on the blockchain.

[0197] 3. Dynamic Trust Value Calculation and Update

[0198] The system periodically evaluates the overall trust value of each vehicle every second: direct trust T directBased on the spatial consistency (position error), temporal consistency (delay), and historical behavior of vehicle data; indirect trust is derived by using Bayesian inference to infer the reliability of the target vehicle based on feedback from neighboring vehicles; finally, the final comprehensive trust value is calculated, and the result is written to the blockchain through transactions to ensure its traceability and immutability for subsequent control and anomaly detection.

[0199] 4. Predictive Control Compensation and Command Generation: Each vehicle periodically synchronizes with the blockchain to obtain the status data of 2-3 neighboring vehicles ahead of it, and filters them based on the trust value T. V For vehicle information with a value greater than 0.7, a trust-weighted average of the states of multiple neighboring vehicles is used to calculate the reference position. and speed Based on the discrete dynamics model of this vehicle, predict the future motion states in τ = 3 steps:

[0200]

[0201] Calculate the control error e(k) between the current trajectory and the reference trajectory, and design the predictive compensation control law:

[0202] u(k)=-Ke(k)

[0203] The feedback gain matrix K is dynamically adjusted according to the traffic environment to achieve adaptive control. Control commands (acceleration / deceleration) are timestamped and output to the vehicle execution layer in real time.

[0204] 5. Anomaly detection and malicious node isolation:

[0205] The flowchart for anomaly detection and queue optimization is as follows: Figure 4 As shown. Within each 1-second detection window, the predicted future trajectory of the lead vehicle is compared with the actual broadcast trajectory. The trajectory deviation is accumulated, and an anomaly score E for each vehicle is calculated. j ;

[0206] Set threshold θ E If vehicle 5 has an abnormal score that meets E for three consecutive cycles j >θ E Furthermore, if the trust value drops below 0.5, the RSU node immediately broadcasts an isolation notice via the on-chain smart contract, marking V5 as an "untrusted node," and other vehicles will block V5 data in subsequent collaborative decision-making.

[0207] 6. Dynamic optimization and adjustment of queue structure:

[0208] After isolating malicious nodes, the system re-groups vehicles according to their remaining trust values ​​and priority scores. Priority calculation:

[0209]

[0210] The queue structure is adjusted based on the sorting results: V1 continues as the leader vehicle, V2 and V3, which have high trust values ​​and high reliability, are added to the relay node positions, and the following vehicles are adjusted to V6 and V7. New platooning instructions are broadcast via the blockchain, and each vehicle dynamically reorganizes according to the swapping protocol (lane changes, acceleration / deceleration coordination), ensuring the overall stability and collaborative efficiency of the queue.

[0211] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A blockchain-based trusted collaborative control method for vehicle queuing, characterized in that: The method includes: The vehicle performs its own state perception, signs the state perception data, and then broadcasts the data. After each RSU node receives the broadcast data packet from the vehicle, it first verifies the data, then dynamically divides all RSU nodes into several groups, and after reaching a consensus on a new block within the group, it uploads the data to the blockchain. After the data is uploaded to the blockchain, a comprehensive trust value for the vehicle is calculated by combining the vehicle's direct and indirect trust, and the calculated comprehensive trust value is updated on the blockchain. Establish a predictive control compensation mechanism based on trust-weighted fusion to compensate for communication delays during blockchain synchronization, and output the compensated control commands to the vehicle; Continuously detect abnormal behavior and isolate malicious nodes; The queue structure is dynamically optimized and adjusted based on vehicle priority scores, and optimization instructions are broadcast to vehicles via a blockchain network.

2. The vehicle queuing trusted collaborative control method and system based on blockchain according to claim 1, characterized in that: First, during the vehicle's self-state perception process, each vehicle periodically collects its own motion state data, including: position coordinates (x, y), velocity v, acceleration a, and driving intention (Intent). Then, the collected motion state data is processed into standardized data packets. msg=<VehicleID,(x,y),v,a,Intent,Timestamp> The Timestamp is used to mark the time when the data was generated; Then, the vehicle uses its own private key SK. V The process of performing a digital signature on a data packet is as follows: Hash the original data packet msg to generate a digest: h = Hash(msg) Where Hash(·) represents hash operation; Using the vehicle's private key SK V Encrypt the digest h to generate the digital signature Sign: Sign=Encrypt(SK V ,h) Where Encrypt(·) is the encryption operation; The final broadcast message contains the original data and a signature field: msg_signed=<msg,Sign> The vehicle broadcasts msg_signed to nearby RSU nodes within its coverage area via the V2X communication interface.

3. The vehicle queuing trusted collaborative control method and system based on blockchain according to claim 1, characterized in that: The RSU node first performs digital signature verification on the received vehicle-side broadcast data packets and retains the data packets that pass the verification; at the same time, it checks the integrity and format of the data fields and removes abnormal or corrupted data. Then, based on the number and quality of vehicle messages received and verified within the period, the interaction volume score PoI_Score is calculated: Among them, PoI_Score j I represents the interaction score of the j-th node. valid (i) represents the verification result marker for the i-th message, where I valid (i) = 1 indicates that it is valid, I valid (i) = 0 indicates invalidity; N j W represents the total number of information items for the j-th node. i This represents the importance weight of the i-th message; Then, the RSU nodes are dynamically divided into several groups based on their geographical distribution, traffic density, and PoI scores. Within each group, the RSU node with the highest interaction score is selected as the temporary leader. The temporary leader generates a new block proposal, which contains the vehicle status data cached in this period. All RSU nodes in the group broadcast and verify the proposed block. If the verification is successful, the group enters the confirmation phase. After a preset proportion of nodes in the group have completed the confirmation, the nodes broadcast messages and lock the new block, thus achieving consensus within the group. Finally, cross-group synchronization and global ledger updates are performed. Each group synchronizes the new block digests formed by local consensus across groups, and the edge server aggregates the consensus results of all groups.

4. The vehicle queuing trusted collaborative control method and system based on blockchain according to claim 3, characterized in that: The grouping process for RSU nodes is as follows: 1) Initial screening based on geographical proximity: Prioritize grouping physically adjacent RSU nodes into the same group; 2) Based on traffic density normalization balance: Set a load limit for each target group; if the traffic density of a certain area exceeds the density threshold, split it into multiple subgroups, or move some RSUs into the low-density area group. 3) Sorting and grading based on PoI score: All RSU nodes are sorted from high to low according to their PoI_Score values. A preset proportion of high-scoring nodes are given priority to be assigned as candidate Leader nodes in the group; medium-scoring nodes are used as consensus nodes; nodes with too low scores or those that are currently fully loaded are set as read-only nodes or only perform synchronization tasks and do not participate in consensus for the time being. 4) Ultimately, several groups are formed that satisfy geographical continuity, traffic load balance, and capacity differentiation.

5. The vehicle queuing trusted collaborative control method and system based on blockchain according to claim 1, characterized in that: The process for calculating the vehicle's overall trust value is as follows: First, calculate the vehicle's direct trust score. The vehicle's direct trust score is related to the spatial consistency, temporal consistency, and historical behavior of the vehicle's broadcast data, and is expressed as follows: T direct =ω+e -λ(c+t+m) Where c represents the spatial consistency index, which reflects the error between the location reported by the vehicle and the actual physical location of the neighboring vehicle; t represents the temporal consistency index, which reflects the broadcast delay of vehicle data; m represents the historical trust decay factor, which reflects the impact of long-term accumulated dishonesty; ω represents the basic trust bias value, which prevents excessively low trust in the early stage; and λ represents the exponential decay coefficient, which controls the sensitivity of abnormal behavior to the decline in trust value. Then, the indirect trust score of the vehicle is calculated. Indirect trust infers the reliability of the target vehicle through feedback from neighboring vehicles. Bayesian inference is used to fuse evidence from neighboring vehicles to calculate the indirect trust value. Where q(e) represents the prior probability that the target vehicle behaves normally; ed n q(ed) represents the evidence provided by the nth neighboring vehicle; Ξ represents the set of neighbors supporting the normal behavior of the target vehicle; NΞ represents the set of neighbors supporting the abnormal behavior of the target vehicle; n |e) indicates evidence observed under normal behavior. n The probability of; This indicates that evidence was observed under anomalous behavior. n The probability of; Then, direct trust and indirect trust are weighted and fused to calculate the final comprehensive vehicle trust value T. V : T V =αT direct +βT indirect Where α and β represent the weighting coefficients of direct trust and indirect trust, respectively, α+β=1, and α>β; After each comprehensive trust value calculation is completed, the RSU node will assign the vehicle's corresponding T... V The trust value change record is updated on the chain and appended to the vehicle block data in the form of a transaction.

6. The vehicle queuing trusted collaborative control method and system based on blockchain according to claim 1, characterized in that: The compensation process of the trust-weighted fusion-based predictive control compensation mechanism is as follows: First, the on-chain synchronization information is aggregated, and the vehicle periodically synchronizes the status information and timestamps of several vehicles ahead of it from the on-chain. s And select and adopt the trust value T. V Higher than the set threshold θ T Vehicle data; The system then performs weighted fusion of vehicle state data with different levels of confidence. For example, it assumes that vehicle i receives data from the set of neighboring vehicles. The estimated reference state is obtained by weighting and averaging the synchronized data. Where a j v j and x j Let these represent the acceleration, velocity, and position state of the adjacent vehicle j, respectively. This indicates the corresponding trust value. and These represent the information received by vehicle i from the set of neighboring vehicles. The synchronous data is weighted and averaged to obtain the estimated reference position, velocity, and acceleration state of the neighboring vehicle j; Then, based on the estimated reference state, the vehicle constructs a state prediction for the next τ steps and defines state variables. The vehicle dynamics discrete model is as follows: Where A, B, and C represent time-varying coefficient matrices, u(k) represents control commands, ω(k) and v(k) represent system disturbances and measurement noise, and y(k) represents the observable output of the vehicle system at time k; The predicted state identifier for the next τ steps is: The vehicle calculates the control error based on the error between its current predicted state and the estimated reference state: in, Finally, a predictive compensation controller is designed using the feedback gain matrix K: u(k)=-Ke(k) K is dynamically obtained using a gain scheduling mechanism; the control instruction u(k) is bound to a timestamp t. s The output is sent to the vehicle execution layer to achieve vehicle control.

7. The blockchain-based trusted collaborative control method and system for vehicle queuing according to claim 1, characterized in that: During the continuous process of detecting abnormal behavior and isolating malicious nodes, the deviation between the predicted trajectory and the actual trajectory is first detected. Within each cycle, the vehicle end predicts the future τ-step state of the neighboring vehicles based on the neighboring vehicle states synchronized on the chain. At the same time, the actual broadcast status y of the neighboring vehicle j is received via V2X. j (k+τ), calculate the deviation between their trajectories: The weighted sum of all deviations within a time window is defined as the anomaly score E for vehicle j. j : Where n represents the number of observation steps within the detection period, γ k The weighting coefficient for time step k; Set an abnormal threshold θ E If the anomaly score of vehicle j satisfies: E j >θ E If vehicle j is found to be behaving abnormally, it will be immediately isolated. Simultaneously, an isolation notice will be issued on-chain via a smart contract, marking vehicle j as an "untrusted node," updating the on-chain state, and lowering vehicle j's trust value. To the lowest level.

8. The blockchain-based trusted collaborative control method and system for vehicle queuing according to claim 1, characterized in that: During the dynamic optimization and adjustment of the queue structure, the vehicles in the queue are first given a priority score. i The calculation, and the priority function, are defined as follows: Where, d i d represents the distance from vehicle i to the leader vehicle in the queue; max R represents the maximum length of the queue when it is stable. i This represents the historical reliability score of vehicle i. α1 represents the trust value of vehicle i; α2 and α3 represent the weight coefficients of each factor, and α1+α2+α3=1; When an abnormal vehicle appears, the system will determine the priority of each vehicle. i The values ​​are sorted, and higher-priority vehicles are placed in key positions, lower-priority vehicles are placed at the end of the queue, and abnormal vehicles are removed from the queue.

9. A blockchain-based trusted collaborative control method and system for vehicle queuing according to claim 8, characterized in that: The optimized and adjusted queue reorganization scheme is generated by the RSU node, and the optimization instructions of the reorganization scheme are broadcast to each vehicle through the blockchain. The optimization instructions include: new platooning order, new target position for each vehicle, update of car-following reference object, safe distance and adjustment of car-following strategy parameters; After receiving the reorganization and optimization instruction, each vehicle autonomously adjusts its queue position according to a unified safety swapping protocol, and a new queue is formed under the control of the controller.

10. A system for executing the blockchain-based trusted collaborative control method for vehicle queuing as described in any one of claims 1-9, characterized in that: The system includes a vehicle-mounted blockchain light node client, a predictive control compensation module, a dynamic trust management module, an anomaly detection module, several roadside units (RSUs), and an edge server. The vehicle-mounted blockchain light node client is deployed in the vehicle, and the vehicle communicates with the RSUs via a V2X communication module. The roadside units are connected to the edge server. The vehicle-side blockchain light node client performs its own state awareness, signs the state awareness data, and then broadcasts the data. Roadside Units (RSUs) verify data and upload it to the blockchain using a consensus algorithm. After the data is uploaded to the blockchain, the dynamic trust management module calculates the vehicle's comprehensive trust value by combining the vehicle's direct and indirect trust, and updates the calculated comprehensive trust value on the blockchain. The predictive control compensation module establishes a trust-weighted fusion-based predictive control compensation mechanism to compensate for communication delays during blockchain synchronization and outputs the compensated control commands to the vehicle. The anomaly detection module continuously detects abnormal behavior and isolates malicious nodes; Ultimately, the roadside unit (RSU) dynamically optimizes and adjusts the vehicle priority scoring queue structure, and broadcasts the optimization instructions to each vehicle via the blockchain network.

Images