Blockchain-based platoon vehicle-to-vehicle communication method, device, equipment and storage medium

Abstract

This application discloses a blockchain-based method, apparatus, device, and storage medium for vehicle-to-vehicle communication in platooning, relating to the field of intelligent transportation technology. The disclosed method includes: responding to a platooning application sent by a requesting vehicle, acquiring platooning application data; verifying the identity of the requesting vehicle corresponding to the platooning application data based on the platooning application data, obtaining an identity verification result; and, if the identity verification result is successful, generating an platooning token and sending it to the requesting vehicle, enabling the requesting vehicle to communicate with the platooning vehicles based on the platooning token. This achieves legitimate vehicle-to-vehicle communication between the requesting vehicle and the platooning vehicles using the platooning token, effectively verifying the legitimacy of the platooning vehicle's identity, ensuring the security of vehicle-to-vehicle communication in platooning, and preventing vehicles from falsifying signals to infiltrate the platoon.

Description

Technical Field

[0001] This application relates to the field of intelligent transportation technology, and in particular to a method, apparatus, device and storage medium for vehicle-to-vehicle communication in platooning based on blockchain. Background Technology

[0002] With the development of intelligent transportation technology, vehicle platooning has become a key direction for improving road traffic efficiency and driving safety. Vehicle platooning, through a collaborative mode where a lead vehicle guides and subsequent vehicles closely follow, enables vehicles to share speed, acceleration, braking status, and steering information in real time via vehicle-to-vehicle communication, thereby achieving low-space, highly coordinated platooning operations. In this highly dynamic, low-latency communication environment, reliable identification of each other by vehicles becomes a prerequisite for ensuring platooning safety.

[0003] In existing technologies, vehicle identity authentication primarily relies on the Public Key Infrastructure (PKI) system, where Certificate Authorities (CAs) issue digital certificates to vehicles. During communication, vehicles verify the legitimacy of the other party's certificate to confirm their identity. When a vehicle certificate is stolen or poses a risk, the management agency adds it to a certificate revocation list and distributes it across the network. Each vehicle then updates its revocation list to achieve identity filtering. However, this type of solution is highly dependent on the operational status of a centralized institution, and the global synchronization of revocation information is delayed. In high-frequency vehicle-to-vehicle communication environments, it is difficult to take effect promptly, easily creating a security window.

[0004] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0005] The main purpose of this application is to provide a blockchain-based vehicle-to-vehicle communication method, device, equipment, and storage medium for platooning, aiming to solve the technical problem of how to achieve real-time reliable verification of the identity of vehicles entering the platoon and rapid failure control in a highly dynamic communication environment of vehicle platooning.

[0006] To achieve the above objectives, this application proposes a blockchain-based vehicle-to-vehicle communication method for platooning, the method comprising: In response to a vehicle's request to join the platoon, retrieve the platoon application data; The identity of the application vehicle corresponding to the queuing application data is verified based on the queuing application data to obtain the identity verification result; When the authentication result is successful, an enlistment token is generated and sent to the requesting vehicle, so that the requesting vehicle can communicate with the platooning vehicles based on the enlistment token.

[0007] In one embodiment, the step of verifying the identity of the application vehicle corresponding to the queuing application data based on the queuing application data and obtaining the identity verification result includes: Obtain the historical behavior records of the vehicle being applied for; Query the public key information and certificate revocation status corresponding to the applied vehicle from the blockchain network; The applicant vehicle is authenticated based on at least one of the public key information, the certificate revocation status, and the historical behavior records to obtain the authentication result.

[0008] In one embodiment, the step of authenticating the applicant vehicle based on at least one of the public key information, the certificate revocation status, and the historical behavior records to obtain an authentication result includes: The digital signature in the queuing application data is verified based on the public key information to determine whether the queuing application data is generated by the private key signature corresponding to the application vehicle, and the signature verification result is obtained. When the signature verification result is that the signature verification is successful, the application vehicle is determined to be on the revocation list based on the certificate revocation status, and the revocation verification result is obtained. When the revocation verification result indicates that the applicant vehicle is not in the revocation list, a credit assessment is performed based on the historical behavior records to obtain a credit assessment result. An authentication result is generated based on the reputation assessment result.

[0009] In one embodiment, after the step of generating an enqueue token and sending it to the requesting vehicle when the authentication result is successful, so that the requesting vehicle can communicate with the platooned vehicles based on the enqueue token, the method further includes: During platooning operations, the system receives vehicle-to-vehicle communication data sent by the requesting vehicle and extracts the platooning token carried in the vehicle-to-vehicle communication data. The signature and validity period of the enqueue token are verified to determine whether the enqueue token is in a valid state, and the token verification result is obtained. When the token verification result is invalid, an exception report transaction is generated; The abnormal report transaction is written into a block to form an on-chain behavior record, and subsequent vehicle-to-vehicle communication of the applicant vehicle is restricted based on the on-chain behavior record.

[0010] In one embodiment, the step of writing the anomaly report transaction into a block to form an on-chain behavior record, and restricting subsequent vehicle-to-vehicle communication of the applicant vehicle based on the on-chain behavior record includes: Anomaly statistics are generated based on the number of abnormal records corresponding to the applied vehicle in the on-chain behavior records; When the abnormal statistical result exceeds a preset abnormal threshold, a revocation update transaction is generated; Write the revocation update transaction into a block to update the certificate revocation status of the applicant vehicle, and obtain the updated certificate revocation status; The updated certificate revocation status is broadcast to the platoon vehicles so that the platoon vehicles stop receiving vehicle-to-vehicle communication data sent by the applicant vehicle based on the platooning token; The applying vehicle is removed from the current fleet based on the updated certificate revocation status to complete the restriction process.

[0011] In one embodiment, before the step of obtaining queuing application data in response to a queuing application sent by the requesting vehicle, the method further includes: A blockchain network is constructed, in which a trusted management agency, roadside nodes, and vehicle nodes jointly participate; The vehicle's unique identifier and the public key are written into the blockchain network to obtain the vehicle identity registration record; Forming a fleet based on the vehicle identity registration record and generating a fleet session identifier to receive joining request data according to the fleet.

[0012] In one embodiment, the step of forming a platoon and generating a platoon session identifier based on the vehicle identity registration record, and receiving platoon entry request data according to the platoon, includes: Forming a platoon based on the vehicle identity registration record and generating a platoon session identifier, then broadcasting the platoon session identifier via vehicle-to-vehicle communication; Listen for the queuing request corresponding to the queuing session identifier, and establish a communication connection with the requesting vehicle when the queuing request is received; Receive queuing request data based on the communication connection.

[0013] In addition, to achieve the above objectives, this application also proposes a blockchain-based vehicle-to-vehicle communication device for platooning, which includes: a platooning application module, used to obtain platooning application data in response to an application vehicle's platooning application; The identity verification module is used to verify the identity of the application vehicle corresponding to the queuing application data based on the queuing application data, and obtain the identity verification result; The vehicle-to-vehicle communication module is used to generate an enlistment token and send it to the requesting vehicle when the authentication result is successful, so that the requesting vehicle can communicate with the platooned vehicles based on the enlistment token.

[0014] Furthermore, to achieve the above objectives, this application also proposes a blockchain-based vehicle-to-vehicle communication device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the blockchain-based vehicle-to-vehicle communication method described above.

[0015] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the blockchain-based platooning vehicle-to-vehicle communication method described above.

[0016] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the blockchain-based platooning vehicle-to-vehicle communication method described above.

[0017] One or more technical solutions proposed in this application have at least the following technical effects: Based on blockchain technology, this approach addresses the shortcomings of existing centralized authentication methods based on public key infrastructure (PKI). These methods involve obtaining corresponding platooning application data in response to vehicle applications, verifying the identity of the applicant vehicle based on this data, generating and sending an entry token to the applicant vehicle after successful verification, and enabling the applicant vehicle to communicate with other vehicles in the platoon using this token. This resolves the single point of failure and delayed certificate revocation list updates inherent in centralized authentication based on public key infrastructure. Furthermore, it mitigates the vulnerability of malicious vehicles that forge communication signals to infiltrate the platoon, thus compromising the security of vehicle-to-vehicle communication. Additionally, traditional authentication methods lack effective management of records related to vehicle entry verification. Compared to existing technologies, this approach achieves decentralized identity authentication for applicant vehicles in platooning communication, effectively verifying the legitimacy of their entry status. It avoids the risk of malicious vehicles forging signals to infiltrate the platoon from the entry stage, ensuring the security of vehicle-to-vehicle communication. Leveraging the characteristics of blockchain, it enables traceability of identity verification operations, improving the robustness of the vehicle-to-vehicle communication authentication system. Simultaneously, the entry token mechanism balances authentication efficiency and communication security in vehicle-to-vehicle communication. Attached Figure Description

[0018] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0019] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is a flowchart illustrating an embodiment of the blockchain-based vehicle-to-vehicle communication method for platooning in this application. Figure 2 This is a schematic diagram of the blockchain-based vehicle-to-vehicle communication system architecture provided in Embodiment 1 of the blockchain-based vehicle-to-vehicle communication method of this application. Figure 3 This is a schematic diagram of the CAN bus network topology provided in Embodiment 1 of the blockchain-based vehicle-to-vehicle communication method for platooning in this application. Figure 4 This is a schematic diagram illustrating the relationship between the cloud, roadside, and vehicle terminals in Embodiment 1 of the blockchain-based vehicle-to-vehicle communication method for platooning, as provided in this application. Figure 5 This is a flowchart illustrating Embodiment 2 of the blockchain-based vehicle-to-vehicle communication method for platooning in this application. Figure 6 A simplified flowchart illustrating the blockchain-based vehicle-to-vehicle communication method for platooning provided in Embodiment 2 of this application; Figure 7 This is a schematic diagram of the module structure of a blockchain-based vehicle-to-vehicle communication device in an embodiment of this application; Figure 8 This is a schematic diagram of the device structure of the hardware operating environment involved in the blockchain-based vehicle-to-vehicle communication method in this application embodiment.

[0021] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0022] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0023] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0024] The main solution of this application embodiment is: in response to the queuing application sent by the requesting vehicle, obtain queuing application data; verify the identity of the requesting vehicle corresponding to the queuing application data according to the queuing application data, and obtain the identity verification result; when the identity verification result is successful, generate a queuing token and send it to the requesting vehicle, so that the requesting vehicle can communicate with the queuing vehicles according to the queuing token.

[0025] In this embodiment, for ease of description, the following description focuses on identifying a blockchain-based vehicle-to-vehicle communication device for platooning.

[0026] To address the limitations of existing technologies in achieving real-time, reliable verification and rapid invalidation control of vehicles joining a platoon in the highly dynamic communication environment of vehicle platooning, this application provides a solution. Based on blockchain technology, this solution addresses the shortcomings of existing centralized authentication systems based on public key infrastructure, such as single points of failure, delayed certificate revocation list updates, and malicious vehicles forging communication signals to infiltrate the platoon. This solution involves obtaining platooning application data in response to a request from a vehicle, verifying the vehicle's identity based on the data, generating and sending a platooning token to the vehicle upon successful verification, and enabling the vehicle to communicate with other vehicles in the platoon using this token. Vehicle platooning makes it difficult to effectively guarantee the security of vehicle-to-vehicle communication within the platoon. Furthermore, traditional authentication methods lack effective management of records related to vehicle entry identity verification. Compared to existing technologies, this approach achieves decentralized identity authentication for vehicles applying to join the platoon during vehicle-to-vehicle communication, effectively verifying the legitimacy of the applicant vehicle's entry identity. It avoids the risk of malicious vehicles forging signals and infiltrating the platoon from the entry stage, ensuring the security of vehicle-to-vehicle communication. Leveraging the characteristics of blockchain, it achieves traceability of identity verification operations, improving the robustness of the vehicle-to-vehicle communication identity authentication system. Simultaneously, the entry token mechanism balances authentication efficiency and communication security in vehicle-to-vehicle communication.

[0027] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device capable of performing the above functions, such as a blockchain-based platoon vehicle-to-vehicle communication device. The following description uses a blockchain-based platoon vehicle-to-vehicle communication device as an example to illustrate this embodiment and the subsequent embodiments.

[0028] Based on this, embodiments of this application provide a blockchain-based method for vehicle-to-vehicle communication in platoons, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the blockchain-based vehicle-to-vehicle communication method for platooning according to this application.

[0029] In this embodiment, the blockchain-based vehicle-to-vehicle communication method for platooning includes steps S10 to S30: Step S10: In response to the queuing application sent by the requesting vehicle, obtain the queuing application data; It should be noted that a platooning application is a request to join a vehicle platoon by the applicant vehicle to the verification node. It is a formal application by the applicant vehicle to become a platoon member, and the applicant vehicle will submit the relevant identity and application information to complete the request.

[0030] Additionally, the queuing application data is a collection of various relevant information contained in the queuing application. It is the core basis for the verification node to verify the identity of the applying vehicle, including key information such as vehicle identity identifier, current timestamp, queue session ID, and digital signature of the applying vehicle.

[0031] Understandably, once the verification node detects and accepts the queuing application initiated by the applicant vehicle, it extracts queuing application data containing various key information from the application to prepare data for subsequent identity verification work.

[0032] Reference Figure 2 , Figure 2 This is a schematic diagram of the blockchain-based vehicle-to-vehicle communication system architecture, representing the first embodiment of the blockchain-based vehicle-to-vehicle communication method for platooning in this application.

[0033] like Figure 2As shown, from top to bottom, the system consists of four layers: the business layer, the platform layer, the network side, and the terminal side. Arrows connect these layers to indicate data flow and dependencies. The business layer, at the top, encompasses four major business scenarios: path planning, autonomous driving, collaborative operations, and remote driving. These scenarios represent the ultimate application goals of the vehicle-to-everything (V2X) system. Below the business layer, the platform layer provides support for the upper-layer business and is divided into five functional modules: terminal and user authentication management, data management and storage, intelligent operation and supervision, information query, and security. The terminal and user authentication management module covers vehicle authentication, user authentication, infrastructure access authentication, and terminal supervision. The data management and storage module manages perception data, positioning data, map data, and control data. The intelligent operation and supervision module provides data analysis and fusion, fault warning, path planning, job scheduling, video surveillance, and remote control functions. The information query module supports queries for vehicle information, network status, job information, and equipment status. The security module includes security mechanisms such as boundary protection, IPS, access control, identity management, key management, digital certificate management, encryption machine management, and security auditing. The network side, located below the platform layer, is the communication infrastructure connecting the platform and terminals. It includes both LTE-V2X and 4G / 5G networks, and provides QoS guarantee mechanisms such as MEC and network slicing, as well as security functions such as authentication, secure access, access control, traffic monitoring, communication encryption, and protocol analysis. The terminal side, located at the bottom of the architecture, is the physical carrier of the vehicle-to-everything (V2X) system. It comprises five main components: a perception module, a communication module, a positioning module, a control and decision-making module, and a security module. The perception module integrates sensors such as cameras, infrared radar, and lidar for environmental perception. The communication module supports 4G and 5G communication and RSU / OBU devices for vehicle-to-infrastructure (V2I) communication. The positioning module uses RTK positioning, sensor positioning, and positioning fusion algorithms to provide high-precision location services. The control and decision-making module implements vehicle control through the onboard controller, CAN bus, and collaborative algorithms. The security module ensures data security and application security.

[0034] Reference Figure 3 , Figure 3 This is a schematic diagram of the CAN bus network topology of the first embodiment of the blockchain-based vehicle-to-vehicle communication method for platooning in this application.

[0035] like Figure 3The diagram shows the CAN bus network topology, which uses a hierarchical bus structure to divide the vehicle's electronic control units into different network areas according to their functional and speed requirements. Six CAN buses are arranged vertically on the left side of the diagram, from top to bottom: 250K CAN1, 250K CAN2, 250K CAN3, 250K CAN4, 250K CAN5, and 500K CAN6. These buses are interconnected through a central gateway, forming a complete vehicle communication backbone network. The powertrain CAN area is located at the top layer and includes five control units: EAC, EPS, DCDC, PDU, and MCU. These units are connected to the 250K CAN1 bus via a five-in-one integrated module and are responsible for the control and management of the vehicle's powertrain system. Among them, EAC is the electric air conditioning compressor controller, EPS is the electric power steering system, DCDC is the DC-DC converter, PDU is the power distribution unit, and MCU is the motor control unit. This area is the core of the vehicle's power output. The VCU, as the vehicle controller, is also connected to the 250K CAN1 bus and is the central management unit of the vehicle's powertrain CAN, responsible for coordinating the work of various power components. The new energy TBOX, as the vehicle communication terminal, is also connected to the 250K CAN1 bus and undertakes the communication function between the vehicle and the external network. It can realize the transmission and reception of V2V communication data and the submission of blockchain transactions. The main OBD diagnostic interface is also connected to this bus area for vehicle fault diagnosis and data reading. The vehicle's CAN bus area is located on the second layer. It connects to the IC instrument cluster controller, low-speed alarm, TPMS tire pressure monitoring system, infotainment system output, BCM body control module, DCM door control module, and LDWS / FCW lane departure warning / forward collision warning system via a 250K CAN2 bus. These units are responsible for vehicle comfort, safety, and infotainment functions. The LDWS / FCW system is directly related to platooning safety, providing environmental perception and warning information for platooning. The 250K CAN3 bus area connects to the SCU system control unit, auxiliary OBD diagnostic interface, EBS / ESC electronic braking system / electronic stability control system, and EPB electronic parking brake system. This area focuses on chassis control and safety systems. The EBS / ESC is a key component for achieving synchronized braking and stability control in vehicle platooning, working closely with V2V communication for real-time synchronization of braking information. The area within the blue dashed box on the right side of the diagram is the Battery Management System (BMS) area, which includes the BMS, battery swapping controller, TMS thermal management system, and charging pile / battery swapping station interface. This area is connected to the vehicle network via an independent network. The BMS is responsible for the status monitoring and safety management of the power battery and is a core component of new energy vehicles. The battery swapping controller and charging pile interface support the vehicle's energy replenishment function.The 250K CAN4, 250K CAN5, and 500K CAN6 buses are shown in the diagram as reserved or extended buses. Among them, the 500K CAN6 bus has a higher speed and connects the ADU autonomous driving unit and the EHPS electric hydraulic power steering system. As an autonomous driving control unit, the ADU is the direct application object of the platoon vehicle identity authentication method. It is responsible for executing the autonomous driving decisions of the lead vehicle or following vehicle and needs to work with blockchain light nodes to verify the identity of the communication object. The EHPS provides steering assistance support. The entire architecture embodies the modern automotive distributed electronic and electrical design philosophy. Each functional domain is separated by buses of different speeds and interconnected through gateways. This ensures reliable communication for power and safety systems with high real-time requirements while also supporting the transmission of non-real-time data such as infotainment. It provides the in-vehicle network deployment foundation for blockchain-based vehicle identity authentication. In particular, the new energy TBOX, as the vehicle network communication entry point and ADU, as the autonomous driving decision center, are key hardware carriers for realizing the integration of on-chain identity verification and off-chain vehicle control. Vehicle status data generated by control units in each CAN bus area can be uploaded to the blockchain network through the TBOX for reputation assessment and behavior auditing of smart contracts. At the same time, it receives authentication results and dynamic token information from the blockchain to realize identity authentication and vehicle control.

[0036] Step S20: Verify the identity of the application vehicle corresponding to the queuing application data based on the queuing application data, and obtain the identity verification result; Understandably, the verification node calls the queuing authentication smart contract deployed on the blockchain to verify the identity of the applicant vehicle based on the extracted queuing application data. It sequentially completes the verification of identity authenticity, the review of identity legality, and the optional reputation assessment. Based on the verification results, it determines whether the identity verification is passed or rejected and records the result as a transaction on the blockchain.

[0037] In one feasible implementation, step S20 may include steps S21 to S23: Step S21: Obtain the historical behavior records of the vehicle being applied for; It should be noted that the historical behavior record is a collection of various behavioral data generated during the past participation of the applying vehicle in vehicle platooning, covering various behavioral information such as whether the vehicle has frequent abnormal exit violations. This record will be permanently stored on the blockchain and has the characteristic of being tamper-proof.

[0038] Understandably, retrieving various past behavioral data of the applicant vehicle from the blockchain and integrating them to form a complete historical behavioral record of the applicant vehicle provides behavioral reference for subsequent identity verification work.

[0039] Step S22: Query the public key information and certificate revocation status corresponding to the applied vehicle from the blockchain network; It should be noted that the public key information is the public key-related data in the asymmetric encryption key generated by the trusted management agency for the vehicle application. This information will be stored on the blockchain as a transaction when the vehicle is first registered and is the core data basis for verifying the validity of the digital signature of the vehicle application.

[0040] Additionally, the certificate revocation status refers to whether the applicant vehicle's identity certificate has been included in the certificate revocation list. The certificate revocation list is maintained and updated by a trusted management agency and stored on the blockchain, ensuring that the status information is globally consistent and can be updated in real time.

[0041] Understandably, the process involves retrieving the registration information corresponding to the applied vehicle from the blockchain network and extracting the public key information from it. At the same time, the on-chain certificate revocation list is queried to confirm the certificate revocation status corresponding to the applied vehicle.

[0042] Step S23: Verify the identity of the applicant vehicle based on at least one of the public key information, the certificate revocation status, and the historical behavior record to obtain the identity verification result.

[0043] Understandably, identity verification is performed on the applying vehicle based on at least one item from the public key information certificate revocation status historical behavior record, and the corresponding identity verification result is obtained based on the actual verification situation.

[0044] In one feasible implementation, step S23 may include steps S231 to S234: Step S231: Verify the digital signature in the queuing application data according to the public key information to determine whether the queuing application data is generated by the private key signature corresponding to the application vehicle, and obtain the signature verification result; It should be noted that a digital signature is a unique identifier generated by the applicant vehicle after encrypting the application data using its own private key. It is the core basis for verifying the source and integrity of the application data and can effectively prevent the data from being tampered with or forged.

[0045] Additionally, the private key is the secret key in the asymmetric encryption key generated by the trusted management agency for the applying vehicle. It is held and used only by the applying vehicle and is the key to generating the digital signature. It will not be disclosed to other nodes or agencies.

[0046] Furthermore, the signature verification result is the judgment result obtained after verifying the digital signature in the joining application data. There are only two possibilities: verification passed or verification failed. It serves as the basis for subsequent identity verification.

[0047] Understandably, the queuing authentication smart contract on the blockchain is invoked, using the public key information of the applying vehicle as the verification basis. The validity of the digital signature attached to the queuing application data is verified to determine whether the digital signature is exclusively generated by the private key corresponding to the applying vehicle, and the corresponding signature verification result is obtained based on the actual verification situation.

[0048] Step S232: When the signature verification result is that the signature verification is successful, determine whether the application vehicle is in the revocation list according to the certificate revocation status, and obtain the revocation verification result; It should be noted that the revocation verification result is a judgment result obtained after determining whether the applicant vehicle is on the revocation list based on the certificate revocation status. It is divided into two categories: not on the revocation list and on the revocation list. It is a key judgment result connecting signature verification and credit assessment.

[0049] Additionally, the revocation list, or Certificate Revocation List (CRL), is a list that stores information about vehicles whose identity certificates have been revoked. It is maintained by a trusted management organization and updated in real time on the blockchain, and can be queried by all verification nodes in real time.

[0050] Understandably, assuming the signature verification result is successful, the latest certificate revocation list is retrieved from the blockchain, and the corresponding certificate revocation status is checked based on the applicant vehicle's identity information to determine whether the applicant vehicle has been included in the revocation list, thereby obtaining the corresponding revocation verification result.

[0051] Step S233: When the revocation verification result is that the applicant vehicle is not in the revocation list, a credit assessment is performed based on the historical behavior record to obtain a credit assessment result; It should be noted that the credit assessment is a process of comprehensively evaluating the vehicle's behavior in platooning based on the vehicle's historical behavior records. The evaluation process is automatically executed by a smart contract, and the evaluation dimensions cover behaviors such as abnormal vehicle exit and illegal driving.

[0052] In addition, the credit assessment result is the judgment result obtained after the credit assessment of the applicant vehicle. It reflects the vehicle's behavioral credit status in the form of quantitative scores or levels and is an important reference for carrying out the final identity verification.

[0053] Understandably, assuming the revocation verification result shows the applicant vehicle is not on the revocation list, the platooning authentication smart contract retrieves the applicant vehicle's complete historical behavior record from the blockchain, extracts various behavioral indicators related to platooning, normalizes them, and comprehensively calculates the applicant vehicle's reputation score based on these indicators. This score is then compared with a preset reputation score threshold to obtain the corresponding reputation assessment result. The reputation score calculation formula is as follows:

[0054] In the formula, R is the vehicle's overall reputation score; normCount is the number of abnormal vehicle behaviors; normAccel is the vehicle's sudden acceleration or deceleration behavior; and normTokenExpire is the vehicle's token expiration behavior. Here are the weighting coefficients corresponding to normCount; The weighting coefficients corresponding to normAccel; This is the weight coefficient corresponding to normTokenExpire.

[0055] Step S234: Generate an identity verification result based on the reputation assessment result.

[0056] Understandably, the credit score in the credit assessment result is compared with the preset score threshold in the team entry authentication smart contract. If the credit score of the applicant vehicle reaches or exceeds the preset threshold, an identity verification result is generated; if the credit score of the applicant vehicle is lower than the preset threshold, an identity verification result is generated. At the same time, the final identity verification result and the reason for the judgment are recorded as a transaction on the blockchain.

[0057] Step S30: When the authentication result is successful, an enlistment token is generated and sent to the requesting vehicle, so that the requesting vehicle can communicate with the platooning vehicles based on the enlistment token.

[0058] It should be noted that the queuing token is a dynamic and time-limited identity credential generated by the verification node for an applicant vehicle that has passed identity verification. This credential contains key information such as vehicle ID, queue session ID, token validity period, and issuer signature, and is the legal basis for the applicant vehicle to communicate with vehicles in the queuing.

[0059] In addition, vehicle-to-vehicle (V2V) communication is a communication method that enables information exchange between vehicles in a platoon. It can synchronize driving information such as vehicle speed, braking, and steering in real time and is the core technological foundation for vehicles to closely follow each other in a platoon.

[0060] Understandably, if the identity verification result is successful, the verification node generates a unique platooning token for the applicant vehicle and sends the token to the applicant vehicle. The applicant vehicle can then use this token to conduct legitimate vehicle-to-vehicle communication with other vehicles in the platoon.

[0061] Reference Figure 4 , Figure 4 This is a schematic diagram illustrating the cloud, roadside, and vehicle-side relationships in the first embodiment of the blockchain-based vehicle-to-vehicle communication method for platooning according to this application.

[0062] like Figure 4 As shown, the entire system is divided into three areas: roadside, vehicle-side, and cloud. The flow of information and the interaction between the entities are represented by arrowed lines. The roadside area contains Roadside Units (RSUs). As verification nodes and token issuing nodes of the blockchain network, RSUs play a crucial bridging role between the vehicle-side and the cloud. On the one hand, they receive platooning applications from vehicles seeking certification; on the other hand, they issue dynamic tokens to verified vehicles. They also act as nodes to access the cloud consortium blockchain network for querying and submitting transactions. The vehicle-side area contains entities related to the vehicle queue, divided into three roles: vehicles awaiting authentication, lead vehicles, and authenticated follower vehicles. Vehicles awaiting authentication are follower vehicles that have not yet joined the queue but wish to join. They are responsible for sending a joining request to the RSU and, after obtaining a token, using the token to conduct V2V communication with the lead vehicle. The lead vehicle is the leading vehicle of the queue, responsible for queue formation and member management. It is shown in the diagram as the central node for V2V communication and has bidirectional V2V communication connections with both vehicles awaiting authentication and authenticated follower vehicles. The lead vehicle also acts as a node to access the cloud blockchain network for querying and submitting transactions. Authenticated follower vehicles are queue members who have passed identity verification and hold valid tokens. They maintain coordination with the lead vehicle through V2V communication and use the token to conduct V2V communication to prove their legitimate identity. The cloud-based area showcases the composition of the consortium blockchain network, comprising three types of nodes: a trusted management authority, Roadside Units (RSUs), and lead / member vehicles. These nodes collectively maintain a distributed ledger, enabling consensus and storage functions. The trusted management authority, an authoritative entity such as a traffic management department, is responsible for initial vehicle registration and certificate revocation list management. RSUs and lead / member vehicles participate in blockchain consensus as distributed verification nodes. All nodes achieve data synchronization and state consistency through the distributed ledger consensus and storage mechanism. The core process shown in the diagram includes: a vehicle seeking certification sends a queuing application to the RSU; the RSU invokes a smart contract for distributed identity verification; upon successful verification, a dynamic token is issued to the applicant vehicle; the applicant vehicle uses the token to establish V2V communication with the lead vehicle; the lead vehicle verifies the token's validity and accepts its addition to the queue as a certified follower vehicle; and the lead vehicle and RSU, as blockchain nodes, continuously submit transaction records to the consortium blockchain, ensuring the immutable storage of information such as queuing records, anomaly reports, and certificate revocations.

[0063] In one possible implementation, steps S50 to S80 may be included after step S40: Step S50: During the platooning process, receive the vehicle-to-vehicle communication data sent by the requesting vehicle, and extract the platooning token carried in the vehicle-to-vehicle communication data; It should be noted that vehicle-to-vehicle communication data is a collection of various data sent when a vehicle applies to join the platoon and conducts vehicle-to-vehicle communication with other vehicles in the platoon. It includes coordinated control information required for platooning, such as vehicle speed, braking, and steering. It is the core data for achieving close following of vehicles in platooning. All data carries an entry token as proof of legitimate communication.

[0064] Additionally, the queuing token is a dynamic and time-limited identity credential generated by the verification node for a vehicle that has passed identity verification. It contains information such as vehicle ID, queue ID, session ID, token validity period, and issuer signature. It is the core basis for the vehicle to conduct legitimate vehicle-to-vehicle communication. Once the token expires, the vehicle needs to reapply for it.

[0065] Understandably, during the continuous operation of the platoon, various vehicle-to-vehicle communication data sent by the requesting vehicles are continuously received, and the accompanying platoon entry token is extracted from the received vehicle-to-vehicle communication data to prepare data for subsequent token validity verification.

[0066] Step S60: Verify the signature and validity period of the enqueue token to determine whether the enqueue token is in a valid state and obtain the token verification result; It should be noted that the token verification result is the result obtained after double verification of the signature and validity period of the joining token. It is divided into two categories: the token is in a valid state and the token is in an invalid state. It is the core basis for determining whether to generate an anomaly report for the application vehicle and directly determines whether the subsequent anomaly handling process is initiated.

[0067] Understandably, the queuing tokens extracted from the vehicle-to-vehicle communication data are sequentially subjected to signature verification and validity period verification. The validity of the issuer's signature on the queuing token and whether the token is within the preset validity period are checked. The actual validity status of the queuing token is determined by combining the results of the two verifications, and the corresponding token verification result is obtained accordingly.

[0068] Step S70: When the token verification result is invalid, generate an exception report transaction; It should be noted that the anomaly report transaction is transaction data that records abnormal communication behavior when the application vehicle's entry token is invalid. It includes key information such as the application vehicle's identity, the type of abnormal behavior, and the time of the abnormality. This transaction data will be submitted to the blockchain network as an abnormal behavior record of the application vehicle and is the core data for the subsequent formation of on-chain behavior records.

[0069] Understandably, if the token verification result shows that the queuing token is invalid, a corresponding abnormal report transaction is generated based on the abnormal communication behavior of the invalid token of the vehicle application, so as to prepare data for subsequent on-chain storage and restrictions on vehicle behavior.

[0070] Step S80: Write the anomaly report transaction into a block to form an on-chain behavior record, and restrict subsequent vehicle-to-vehicle communication of the applicant vehicle based on the on-chain behavior record.

[0071] It should be noted that on-chain behavior records are immutable behavior records formed by writing various vehicle behavior-related transaction data into the blockchain. These records include various behavioral information such as abnormal reports of vehicle applications. They are permanently stored on the blockchain and can be queried in real time by all authorized nodes. They serve as an important basis for evaluating and controlling vehicle behavior.

[0072] In addition, the restriction processing is a targeted control measure taken on the subsequent vehicle-to-vehicle communication based on the on-chain behavior records of the applying vehicle. Different control methods can be adopted according to the severity of abnormal behavior, which is an effective means of constraining abnormal vehicle communication behavior in the platoon.

[0073] It is understandable that the generated anomaly report transaction is submitted to the blockchain network and written into a block, forming an on-chain behavior record corresponding to the application vehicle. Based on this on-chain behavior record, corresponding restrictions are imposed on subsequent vehicle-to-vehicle communication of the application vehicle.

[0074] In one feasible implementation, step S80 may include steps S81 to S85: Step S81: Generate anomaly statistics results based on the number of abnormal records corresponding to the application vehicle in the on-chain behavior records; It should be noted that the number of abnormal records is the cumulative number of abnormal communication behaviors, such as token invalidation, recorded in the on-chain behavior record formed after the abnormal report transaction of the vehicle application is written into the blockchain. This number is updated in real time with new abnormal report transactions and is the core quantitative indicator for judging the severity of abnormal behavior of the vehicle application.

[0075] In addition, the anomaly statistics result is a quantitative result obtained by statistically calculating the number of anomaly records of the application vehicle based on the on-chain behavior records. This result is expressed in specific numerical form and is the key basis for determining whether to take measures to revoke the certificate of the application vehicle.

[0076] Understandably, all abnormal report transactions corresponding to the applied vehicle are extracted from the blockchain's on-chain behavior records, the number of abnormal communication behaviors recorded therein is counted, and corresponding abnormal statistical results are generated based on the actual statistical values.

[0077] Step S82: When the abnormal statistics result is greater than the preset abnormal threshold, generate a revocation update transaction; It should be noted that the preset anomaly threshold is a critical value for the number of abnormal records set in advance in the blockchain smart contract. This threshold is the standard for determining whether the abnormal behavior of the applying vehicle reaches the level that requires the revocation of identity credentials. It can be adapted and adjusted according to the security requirements of vehicle platooning.

[0078] Additionally, the revocation update transaction is transaction data used to apply for the inclusion of the applicant vehicle's identity certificate in the certificate revocation list. It contains key information such as the applicant vehicle's identity identifier, abnormal statistical results, and reasons for the revocation application, and is the core data carrier for updating the revocation status of vehicle certificates.

[0079] Understandably, the generated anomaly statistics are compared with the preset anomaly threshold in the smart contract. If the anomaly statistics exceed the preset anomaly threshold, a corresponding revocation update transaction is generated to prepare for the subsequent update of the certificate revocation status.

[0080] Step S83: Write the revocation update transaction into the block to update the certificate revocation status of the applicant vehicle, and obtain the updated certificate revocation status. It should be noted that the certificate revocation status is the status information recorded on the blockchain regarding whether the applied vehicle identity certificate has been included in the certificate revocation list. It is divided into two statuses: not revoked and revoked. This status is maintained by a trusted management institution and can be updated in real time through revocation update transactions. All verification nodes can query it in real time.

[0081] Additionally, the updated certificate revocation status is achieved by writing the revocation update transaction into the blockchain block. This changes the certificate revocation status of the applicant vehicle from "not revoked" to "revoked". This status update is then globally synchronized across the blockchain network to ensure that all nodes obtain consistent status information.

[0082] Understandably, the generated revocation update transaction is submitted to the blockchain network and written into a block. The blockchain's distributed consensus mechanism confirms the transaction, thereby updating the certificate revocation status of the applicant vehicle on the blockchain and obtaining the corresponding updated certificate revocation status.

[0083] Step S84: Broadcast the updated certificate revocation status to the platooning vehicles so that the platooning vehicles stop receiving vehicle-to-vehicle communication data sent by the applicant vehicle based on the platooning token; Understandably, the updated certificate revocation status is broadcast to all vehicles in the platoon, allowing each vehicle in the platoon to obtain the certificate revocation status change information of the applicant vehicle. Based on this, the platoon vehicles stop receiving various vehicle-to-vehicle communication data sent by the applicant vehicle based on the original platoon entry token.

[0084] Step S85: Remove the applicant vehicle from the current platoon according to the updated certificate revocation status to complete the restriction process.

[0085] Understandably, based on the updated certificate revocation status, the removal operation of the platoon member is performed to officially remove the applicant vehicle from the currently running vehicle platoon, thereby completing the restriction on the applicant vehicle's subsequent vehicle-to-vehicle communication.

[0086] This embodiment provides a blockchain-based vehicle-to-vehicle communication method for platooning vehicles. By using distributed identity authentication and dynamic token mechanism based on consortium blockchain, it solves the technical problems of single point of failure, certificate revocation delay and lack of behavior traceability in traditional PKI centralized authentication. It achieves the beneficial effects of decentralized high robustness, millisecond-level real-time revocation, full lifecycle behavior traceability and automated reliable execution, effectively ensuring the safety and reliability of vehicle platooning.

[0087] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in the first embodiment described above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 5 Before step S10, the blockchain-based platooning vehicle-to-vehicle communication method further includes steps S01 to S03: Step S01: Construct a blockchain network, wherein the blockchain network is jointly participated in by a trusted management agency, roadside nodes, and vehicle nodes; It should be noted that a blockchain network is a decentralized network system built by multiple nodes based on a distributed consensus mechanism. It has the characteristics of data immutability, real-time synchronization, and automatic execution of smart contracts, and is the core technology carrier for vehicle platoon identity authentication.

[0088] Additionally, the trusted management institution is an authoritative management body, namely the traffic management department, which is responsible for managing the initial identity information of vehicles and maintaining the certificate revocation list. It is one of the core participants in the blockchain network.

[0089] Additionally, roadside nodes are dedicated network nodes, or roadside units, deployed along roads. They can act as verification nodes for the blockchain network, providing on-chain service proxies and enabling information interaction between the vehicle and the blockchain network.

[0090] Furthermore, vehicle nodes are vehicle terminals that connect to the blockchain network, participate in the consensus process of the blockchain network, and complete their own identity registration and team application, among other related operations.

[0091] Understandably, a trusted management organization would take the lead, with the participation of roadside nodes and vehicle nodes, to build a blockchain network with distributed consensus capabilities, and to determine the functions of each node and the rules for participating in consensus.

[0092] Step S02: Write the vehicle's unique identifier and the public key into the blockchain network to obtain the vehicle identity registration record; It should be noted that a vehicle unique identifier is a unique piece of information used to uniquely identify a vehicle. It is a core identifier that distinguishes different vehicles and can be a unique vehicle-specific information such as a vehicle identification number.

[0093] Additionally, the public key is the public key in the asymmetric encryption key generated for the vehicle by the trusted management organization. It can be made public for other nodes to use and is the core data basis for verifying the validity of the vehicle's digital signature.

[0094] Furthermore, the vehicle identity registration record is an immutable data record formed after the vehicle's unique identifier and public key are written into the blockchain network. It serves as the vehicle's initial identity credential in the blockchain network, and all authorized nodes can query it in real time.

[0095] Understandably, the vehicle's unique identifier and corresponding public key are submitted to the blockchain network as transaction data to complete the on-chain storage of the data and form the vehicle's identity registration record.

[0096] Step S03: Form a platoon based on the vehicle identity registration record and generate a platoon session identifier to receive platoon entry application data according to the platoon.

[0097] It should be noted that the platoon session identifier is a unique identifier generated for newly formed vehicle platoons. It is an exclusive identifier that distinguishes different vehicle platoons and is generated and released to the outside world during the platoon formation process.

[0098] Additionally, the platooning application data is a collection of application-related data submitted by vehicles wishing to join the platoon. It includes vehicle identification, timestamps, platooning session identifiers, and digital signatures, and is the core data for platooning identity verification.

[0099] Understandably, legitimate vehicles are selected based on vehicle identity registration records in the blockchain network to form a platoon, a unique platoon session identifier is generated for the platoon, and the platoon is used to publish platoon formation information and receive platoon entry application data.

[0100] In one feasible implementation, step S03 may include steps S031 to S033: Step S031: Form a fleet based on the vehicle identity registration record and generate a fleet session identifier, and broadcast the fleet session identifier through vehicle-to-vehicle communication; It should be noted that the platoon session identifier is a unique identifier generated for newly formed vehicle platoons. It is an exclusive identifier that distinguishes different vehicle platoons and is used to associate the platoon entry application and various communication behaviors. It is the core association basis for the vehicle to initiate the platoon entry application.

[0101] Understandably, a platoon is formed based on the vehicle's registration record, and a platoon session identifier is generated. This platoon session identifier is then broadcast to the surrounding area via vehicle-to-vehicle communication.

[0102] Step S032: Listen for the queuing request corresponding to the queuing session identifier, and establish a communication connection with the requesting vehicle when the queuing request is received; It should be noted that the platooning request is a request signal initiated by a vehicle seeking to join the platoon after obtaining the platooning session identifier. It is the initial signal for the vehicle to start the platooning process and includes the vehicle's basic identity identifier and the corresponding platooning session identifier.

[0103] In addition, the communication connection is the information transmission link established between the platoon and the requesting vehicle. It is a dedicated channel for transmitting platoon request data and verification information between the two, and has the transmission characteristics of low latency and high stability, which can meet the dynamic communication needs of vehicle platoons.

[0104] Understandably, the system listens for queuing requests corresponding to the queuing session identifier and establishes a communication connection with the requesting vehicle upon receiving the request.

[0105] Step S033: Receive queuing request data based on the communication connection.

[0106] Understandably, based on the communication connection established with the requesting vehicle, the system receives the platooning application data sent by the requesting vehicle.

[0107] This embodiment provides a blockchain-based vehicle-to-vehicle communication method for platooning. By constructing a consortium blockchain network jointly participated in by a trusted management agency, roadside nodes, and vehicle nodes, and writing the vehicle's unique identifier and public key into the blockchain to form an immutable identity registration record, it solves the technical problems of high single-point failure risk and large certificate management delay in the traditional centralized authentication system. It achieves the beneficial effects of decentralized high-availability identity management, real-time global state synchronization, and trusted platooning formation, laying a distributed trust foundation for subsequent platooning applications and verification.

[0108] For example, to help understand the implementation process of the blockchain-based vehicle-to-vehicle communication method for platooning obtained by combining this embodiment with the above embodiment one, please refer to... Figure 6 , Figure 6A simplified flowchart of a blockchain-based vehicle-to-vehicle communication method for platooning is provided, specifically: The four lanes, from left to right, represent the vehicle to be certified, the Roadside Unit (RSU) verification node, the blockchain network and smart contract, and the lead vehicle / queue. The vertical timeline, from top to bottom, indicates the sequence of process progression. The first stage is the S1 initialization and registration prerequisite stage. This stage is the preparatory work before the system runs. The trusted management agency issues initial identity certificates to the vehicles, establishing the digital identity foundation of the vehicles on the blockchain. This corresponds to the process of generating asymmetric encryption key pairs and registering the information to the blockchain when the vehicle leaves the factory or registers for the first time. The second phase consists of the S3 and S4 queuing application and verification phases. This phase includes four key steps. First, the lead vehicle / queue broadcasts the queue session ID to the vehicle to be certified, announcing the queue formation information. Then, the vehicle to be certified sends a queuing application to the Roadside Unit (RSU) verification node and signs it. This application includes information such as the vehicle's identity identifier, timestamp, and queue session ID, and is signed using the vehicle's private key. Next, the RSU verification node calls the queuing authentication smart contract, submitting the verification request to the blockchain network. The smart contract executes three core verification operations: verifying the signature validity to confirm the authenticity of the identity, querying the certificate revocation list on the blockchain to confirm the legality of the identity, and assessing the vehicle's historical reputation to determine its queuing eligibility. After verification, the blockchain network returns the verification result to the Roadside Unit. If the verification is successful, the Roadside Unit issues a dynamic queuing token to the vehicle to be certified. This token has an expiration date and contains information such as the vehicle ID, queue session ID, validity period, and issuer's signature. The third stage is the S5 and S6 queue communication and continuous authentication stage. This stage is marked during queue driving and includes a cyclic structure. Authentication vehicles carry dynamic tokens and communicate with the lead vehicle / queue via V2V messages to realize platoon driving functions such as cooperative adaptive cruise control. At the same time, the lead vehicle / queue will periodically or randomly send re-authentication requests to the vehicles to be authenticated, forming a heartbeat challenge mechanism to prevent token theft or replay attacks, and to ensure continuous secure authentication during queue driving.

[0109] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the blockchain-based vehicle-to-vehicle communication method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0110] This application also provides a blockchain-based vehicle-to-vehicle communication device for platooning, please refer to... Figure 7 The blockchain-based platooning vehicle-to-vehicle communication device includes: The queuing application module 10 is used to respond to the queuing application sent by the applying vehicle and obtain the queuing application data; The identity verification module 20 is used to verify the identity of the application vehicle corresponding to the queuing application data based on the queuing application data, and obtain the identity verification result; The vehicle-to-vehicle communication module 30 is used to generate an enlistment token and send it to the requesting vehicle when the authentication result is passed, so that the requesting vehicle can communicate with the platooning vehicles based on the enlistment token.

[0111] The blockchain-based vehicle-to-vehicle communication device provided in this application, employing the blockchain-based vehicle-to-vehicle communication method described in the above embodiments, can solve the technical problem of how to achieve real-time reliable verification and rapid failure control of the identity of vehicles entering the platoon in a highly dynamic communication environment of vehicle platooning. Compared with the prior art, the beneficial effects of the blockchain-based vehicle-to-vehicle communication device provided in this application are the same as those of the blockchain-based vehicle-to-vehicle communication method provided in the above embodiments, and other technical features in the blockchain-based vehicle-to-vehicle communication device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0112] In one embodiment, the identity verification module 20 is further configured to obtain historical behavior records of the applying vehicle; Query the public key information and certificate revocation status corresponding to the applied vehicle from the blockchain network; The applicant vehicle is authenticated based on at least one of the public key information, the certificate revocation status, and the historical behavior records to obtain the authentication result.

[0113] In one embodiment, the identity verification module 20 is further configured to verify the digital signature in the queuing application data based on the public key information, determine whether the queuing application data is generated by the private key signature corresponding to the application vehicle, and obtain a signature verification result; When the signature verification result is that the signature verification is successful, the application vehicle is determined to be on the revocation list based on the certificate revocation status, and the revocation verification result is obtained. When the revocation verification result indicates that the applicant vehicle is not in the revocation list, a credit assessment is performed based on the historical behavior records to obtain a credit assessment result. An authentication result is generated based on the reputation assessment result.

[0114] In one embodiment, the vehicle-to-vehicle communication module 30 is further configured to receive vehicle-to-vehicle communication data sent by the requesting vehicle during platooning operation, and extract the platooning token carried in the vehicle-to-vehicle communication data; The signature and validity period of the enqueue token are verified to determine whether the enqueue token is in a valid state, and the token verification result is obtained. When the token verification result is invalid, an exception report transaction is generated; The abnormal report transaction is written into a block to form an on-chain behavior record, and subsequent vehicle-to-vehicle communication of the applicant vehicle is restricted based on the on-chain behavior record.

[0115] In one embodiment, the vehicle communication module 30 is further configured to generate anomaly statistics based on the number of anomaly records corresponding to the applying vehicle in the on-chain behavior records; When the abnormal statistical result exceeds a preset abnormal threshold, a revocation update transaction is generated; Write the revocation update transaction into a block to update the certificate revocation status of the applicant vehicle, and obtain the updated certificate revocation status; The updated certificate revocation status is broadcast to the platoon vehicles so that the platoon vehicles stop receiving vehicle-to-vehicle communication data sent by the applicant vehicle based on the platooning token; The applying vehicle is removed from the current fleet based on the updated certificate revocation status to complete the restriction process.

[0116] In one embodiment, the queuing application module 10 is further used to construct a blockchain network, wherein the blockchain network is jointly participated in by a trusted management agency, roadside nodes, and vehicle nodes; The vehicle's unique identifier and the public key are written into the blockchain network to obtain the vehicle identity registration record; Forming a fleet based on the vehicle identity registration record and generating a fleet session identifier to receive joining request data according to the fleet.

[0117] In one embodiment, the queuing application module 10 is further configured to form a queuing based on the vehicle identity registration record and generate a queuing session identifier, and broadcast the queuing session identifier through vehicle-to-vehicle communication; Listen for the queuing request corresponding to the queuing session identifier, and establish a communication connection with the requesting vehicle when the queuing request is received; Receive queuing request data based on the communication connection.

[0118] This application provides a blockchain-based vehicle-to-vehicle communication device for platooning. The blockchain-based vehicle-to-vehicle communication device for platooning includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the blockchain-based vehicle-to-vehicle communication method in Embodiment 1 above.

[0119] The following is for reference. Figure 8This document illustrates a structural schematic diagram of a blockchain-based vehicle-to-vehicle communication device suitable for implementing embodiments of this application. The blockchain-based vehicle-to-vehicle communication device in this application embodiment may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital radio receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 8 The blockchain-based platooning vehicle-to-vehicle communication device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0120] like Figure 8 As shown, a blockchain-based platooning vehicle-to-vehicle communication device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to programs stored in ROM (Read Only Memory) 1002 or programs loaded from storage device 1003 into RAM (Random Access Memory) 1004. RAM 1004 also stores various programs and data required for the operation of the blockchain-based platooning vehicle-to-vehicle communication device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via bus 1005. Input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows blockchain-based platooning vehicle-to-vehicle communication equipment to exchange data with other devices wirelessly or via wired connections. Although the figure shows blockchain-based platooning vehicle-to-vehicle communication equipment with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0121] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0122] The blockchain-based vehicle-to-vehicle communication device provided in this application, employing the blockchain-based vehicle-to-vehicle communication method described in the above embodiments, solves the technical problem of how to achieve real-time reliable verification and rapid failure control of the identity of vehicles entering the platoon in a highly dynamic communication environment of vehicle platooning. Compared with the prior art, the beneficial effects of the blockchain-based vehicle-to-vehicle communication device provided in this application are the same as those of the blockchain-based vehicle-to-vehicle communication method provided in the above embodiments, and other technical features of this blockchain-based vehicle-to-vehicle communication device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0123] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0124] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0125] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the blockchain-based platooning vehicle-to-vehicle communication method in the above embodiments.

[0126] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, RAM (Random Access Memory), ROM (Read Only Memory), Erasable Programmable Read Only Memory (EPROM), optical fiber, CD-ROM (CD-Read Only Memory), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0127] The aforementioned computer-readable storage medium may be included in a blockchain-based platoon vehicle-to-vehicle communication device; or it may exist independently and not be incorporated into a blockchain-based platoon vehicle-to-vehicle communication device.

[0128] The aforementioned computer-readable storage medium carries one or more programs that, when executed by a blockchain-based platooning vehicle-to-vehicle communication device, cause the blockchain-based platooning vehicle-to-vehicle communication device to: in response to an application for platooning sent by an applicant vehicle, acquire platooning application data; verify the identity of the applicant vehicle corresponding to the platooning application data based on the platooning application data, and obtain an identity verification result; and, if the identity verification result is successful, generate an platooning token and send it to the applicant vehicle, so that the applicant vehicle can communicate with the platooning vehicles based on the platooning token.

[0129] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including LAN (Local Area Network) or WAN (Wide Area Network)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0130] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0131] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0132] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the aforementioned blockchain-based vehicle-to-vehicle communication method for platooning. This solves the technical problem of how to achieve real-time reliable verification and rapid failure control of the identity of vehicles entering the platoon in a highly dynamic communication environment of vehicle platooning. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the blockchain-based vehicle-to-vehicle communication method for platooning provided in the above embodiments, and will not be repeated here.

[0133] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the blockchain-based platooning vehicle-to-vehicle communication method described above.

[0134] The computer program product provided in this application solves the technical problem of how to achieve real-time reliable verification and rapid failure control of the identity of vehicles entering the platoon in a highly dynamic communication environment. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the blockchain-based vehicle-to-vehicle communication method for platooning provided in the above embodiments, and will not be repeated here.

[0135] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A blockchain-based method for vehicle-to-vehicle communication in platoons, characterized in that, The method includes: In response to a vehicle's request to join the platoon, retrieve the platoon application data; The identity of the application vehicle corresponding to the queuing application data is verified based on the queuing application data to obtain the identity verification result; When the authentication result is successful, an enlistment token is generated and sent to the requesting vehicle, so that the requesting vehicle can communicate with the platooning vehicles based on the enlistment token.

2. The method as described in claim 1, characterized in that, The step of verifying the identity of the application vehicle corresponding to the queuing application data based on the queuing application data and obtaining the identity verification result includes: Obtain the historical behavior records of the vehicle being applied for; Query the public key information and certificate revocation status corresponding to the applied vehicle from the blockchain network; The applicant vehicle is authenticated based on at least one of the public key information, the certificate revocation status, and the historical behavior records to obtain the authentication result.

3. The method as described in claim 2, characterized in that, The step of verifying the identity of the applicant vehicle based on at least one of the public key information, the certificate revocation status, and the historical behavior record, and obtaining the identity verification result, includes: The digital signature in the queuing application data is verified based on the public key information to determine whether the queuing application data is generated by the private key signature corresponding to the application vehicle, and the signature verification result is obtained. When the signature verification result is that the signature verification is successful, the application vehicle is determined to be on the revocation list based on the certificate revocation status, and the revocation verification result is obtained. When the revocation verification result indicates that the applicant vehicle is not in the revocation list, a credit assessment is performed based on the historical behavior records to obtain a credit assessment result. An authentication result is generated based on the reputation assessment result.

4. The method as described in claim 1, characterized in that, After the step of generating an enlistment token and sending it to the requesting vehicle when the authentication result is successful, so that the requesting vehicle can communicate with the platooned vehicles based on the enlistment token, the method further includes: During platooning operations, the system receives vehicle-to-vehicle communication data sent by the requesting vehicle and extracts the platooning token carried in the vehicle-to-vehicle communication data. The signature and validity period of the enqueue token are verified to determine whether the enqueue token is in a valid state, and the token verification result is obtained. When the token verification result is invalid, an exception report transaction is generated; The abnormal report transaction is written into a block to form an on-chain behavior record, and subsequent vehicle-to-vehicle communication of the applicant vehicle is restricted based on the on-chain behavior record.

5. The method as described in claim 4, characterized in that, The steps of writing the anomaly report transaction into a block to form an on-chain behavior record, and restricting subsequent vehicle-to-vehicle communication of the applicant vehicle based on the on-chain behavior record include: Anomaly statistics are generated based on the number of abnormal records corresponding to the applied vehicle in the on-chain behavior records; When the abnormal statistical result exceeds a preset abnormal threshold, a revocation update transaction is generated; Write the revocation update transaction into a block to update the certificate revocation status of the applicant vehicle, and obtain the updated certificate revocation status; The updated certificate revocation status is broadcast to the platoon vehicles so that the platoon vehicles stop receiving vehicle-to-vehicle communication data sent by the applicant vehicle based on the platooning token; The applying vehicle is removed from the current fleet based on the updated certificate revocation status to complete the restriction process.

6. The method as described in claim 1, characterized in that, Before the step of obtaining queuing application data in response to a queuing application sent by the requesting vehicle, the method further includes: A blockchain network is constructed, in which a trusted management agency, roadside nodes, and vehicle nodes jointly participate; The vehicle's unique identifier and the public key are written into the blockchain network to obtain the vehicle identity registration record; Forming a fleet based on the vehicle identity registration record and generating a fleet session identifier to receive joining request data according to the fleet.

7. The method as described in claim 1, characterized in that, The step of forming a platoon based on the vehicle identity registration record and generating a platoon session identifier to receive platoon entry request data according to the platoon includes: Forming a platoon based on the vehicle identity registration record and generating a platoon session identifier, then broadcasting the platoon session identifier via vehicle-to-vehicle communication; Listen for the queuing request corresponding to the queuing session identifier, and establish a communication connection with the requesting vehicle when the queuing request is received; Receive queuing request data based on the communication connection.

8. A blockchain-based vehicle-to-vehicle communication device for platooning, characterized in that, The device includes: The queuing application module is used to respond to queuing applications sent by applying vehicles and obtain queuing application data; The identity verification module is used to verify the identity of the application vehicle corresponding to the queuing application data based on the queuing application data, and obtain the identity verification result; The vehicle-to-vehicle communication module is used to generate an enlistment token and send it to the requesting vehicle when the authentication result is successful, so that the requesting vehicle can communicate with the platooned vehicles based on the enlistment token.

9. A blockchain-based vehicle-to-vehicle communication device for platooning, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the blockchain-based platooning vehicle-to-vehicle communication method as described in any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the blockchain-based vehicle-to-vehicle communication method as described in any one of claims 1 to 7.

Images