High information security cooperative obstacle avoidance method and system for vehicle networking autonomous vehicle

Abstract

The present application relates to a kind of high information security collaborative obstacle avoidance method and system for vehicle networking automatic driving vehicle, it is related to vehicle networking automatic driving vehicle and vehicle networking network information security field.Vehicle networking automatic driving vehicle realizes high safety operation scene function such as automatic obstacle avoidance when, collaborative obstacle avoidance key business data faces information security challenge such as data protection, information transmission security.The present application adopts the linkage of three kinds of information security methods such as fusion token, serial number and cyclic redundancy check code to realize the data protection and security reinforcement of key business data.In the process that vehicle networking automatic driving vehicle realizes collaborative obstacle avoidance, around the process of data generation, encapsulation transmission, receiving verification, decision execution, form layer by layer progressive data security protection system.The present application combines business token inspection, data frame serial number and redundancy information check technology, realizes the data protection and security communication protection in the key business process of collaborative obstacle avoidance of vehicle networking automatic driving vehicle.

Description

Technical Field

[0001] This invention relates to the field of vehicle networking technology, and in particular to a collaborative obstacle avoidance method and system with high information security for vehicle networking autonomous driving vehicles. Background Technology

[0002] Vehicle-to-everything (V2X) multi-node cooperative obstacle avoidance technology relies on real-time data interaction between vehicles, roadside units, and pedestrians. Its development is influenced by communication technology, cooperative algorithms, and security mechanisms. 5G technology, with its low latency and high reliability, provides crucial support for vehicle-to-everything (V2X) communication, enabling obstacle information to be shared within milliseconds and laying the foundation for multi-node cooperative decision-making. However, autonomous vehicles still face challenges in achieving cooperative obstacle avoidance, including perception fusion errors, the complexity of multi-vehicle cooperative decision-making in dynamic traffic environments, and the impact of communication latency on vehicle control stability.

[0003] In the vehicle-to-everything (V2X) architecture, the obstacle avoidance-related critical business information transmitted between roadside units, vehicle-mounted units, edge computing nodes, and cloud platforms is characterized by diversity and high sensitivity. Specifically, it includes driving safety-related control information such as vehicle control commands and autonomous driving perception data; privacy-sensitive data such as vehicle owner identity information and real-time location data; and public service information such as traffic scheduling and emergency warnings. The integrity and confidentiality of this information are core prerequisites for the reliable operation of the V2X system. For example, if the emergency obstacle avoidance commands generated by the roadside edge computing node are tampered with, it will directly induce a vehicle collision risk.

[0004] Currently, the vehicle-to-everything (V2X) network system faces severe security challenges, and with the introduction of 5G-A / 6G technologies, new risk evolution trends are emerging:

[0005] 1) Flaws in the node identity authentication mechanism: In the open communication environment formed by 5G wide access, identity spoofing attacks occur frequently. Attackers can access the network by forging the identity of vehicle-mounted units or roadside units, leading to the leakage of vehicle identification codes and vehicle owner information.

[0006] 2) Weak data transmission security: As the core link for data interaction between nodes, air communication is vulnerable to eavesdropping and tampering, and traditional encryption mechanisms are difficult to adapt to the actual needs of the highly dynamic scenarios of vehicle networking.

[0007] 3) Insufficient security protection for critical nodes: As a communication hub, the roadside unit has both data aggregation and edge computing functions. Although it improves response speed, it has also become a target of attacks. Existing security components are difficult to effectively defend against malicious program injection targeting edge nodes.

[0008] The aforementioned security risks have spurred the need for security hardening of critical business data, such as collaborative obstacle avoidance. Summary of the Invention

[0009] The purpose of this invention is to overcome the shortcomings of the prior art by providing a highly secure collaborative obstacle avoidance method and system for connected vehicle autonomous driving, so as to solve or partially solve the problem of unsatisfactory security and reliability of existing solutions.

[0010] The objective of this invention can be achieved through the following technical solutions:

[0011] One aspect of the present invention provides a cooperative obstacle avoidance method with high information security for connected vehicle autonomous driving vehicles, comprising the following steps:

[0012] In response to the detection of a sudden obstacle, the system obtains the status information of other connected autonomous vehicles within a preset range, using the current connected autonomous vehicle as a reference, and generates collaborative obstacle avoidance warning data, including obstacle location, warning level, and suggested deceleration value.

[0013] Based on the aforementioned collaborative obstacle avoidance early warning data, core business data for collaborative obstacle avoidance is generated through token, sequence number, and cyclic redundancy check (CRC) processing.

[0014] The core business data of collaborative obstacle avoidance is sent to other connected autonomous vehicles within a preset range;

[0015] Upon receiving the core business data for collaborative obstacle avoidance, verification is performed sequentially using CRC, token, and sequence number checks.

[0016] Upon successful verification, obstacle avoidance is triggered.

[0017] As a preferred technical solution, the token, serial number, and CRC processing includes the following steps:

[0018] Based on the unique identifier, data validity period and cryptographic signature of the current connected vehicle autonomous driving vehicle, a token is generated and added to the header of the collaborative obstacle avoidance warning data;

[0019] Assign a sequence number to the current data frame based on the timestamp and the sequence number of data of the same type;

[0020] The token, collaborative obstacle avoidance early warning data, and serial number are integrated to generate a CRC check code, forming the core business data for collaborative obstacle avoidance.

[0021] As a preferred technical solution, the process of sequentially performing CRC, token, and serial number verification includes the following steps:

[0022] Receive core business data on collaborative obstacle avoidance sent by other connected vehicle autonomous vehicles;

[0023] Data frames are obtained by parsing the core business data of the collaborative obstacle avoidance;

[0024] Perform CRC check on the data frame to verify the integrity of the data packet;

[0025] The data is subjected to frame token verification to check the validity of the sender's identity ID, as well as the time validity and signature validity of the data frame, thereby realizing the sender's identity verification.

[0026] Based on the data frame, the sequence number is verified to confirm the order of the data frame and check the order of collaborative obstacle avoidance data service processing, thereby realizing the service order verification of the data frame.

[0027] As a preferred technical solution, the CRC verification process includes the following steps:

[0028] Extract the first CRC check value from the tail of the collaborative obstacle avoidance core business data, and obtain the second CRC check value through the CRC-32 algorithm;

[0029] Determine whether the first CRC check value is equal to the second CRC check value. If yes, proceed to the next verification step; otherwise, discard the data packet and send a retransmission command to the sender.

[0030] As a preferred technical solution, the frame token verification process includes the following steps:

[0031] The system requests the sender's token identity information from the cloud platform. After verifying whether the token has been registered and is within its validity period on the cloud platform, the system obtains the verification result from the cloud platform. If the verification is successful, the data frame is valid and subsequent processing continues. If the verification fails, the data frame is discarded and an anomaly is reported to the cloud platform.

[0032] As a preferred technical solution, the serial number verification process includes the following steps:

[0033] Query the maximum sequence number of the data sent by the sender in the local storage and compare it with the sequence number of the current data packet:

[0034] If the current sequence number equals the previous maximum sequence number plus 1, then the verification passes.

[0035] If the current sequence number is less than the previous maximum sequence number + 1, it is considered a duplicate data and is discarded.

[0036] If the current sequence number is greater than the previous maximum sequence number + 1, it is determined to be a lost frame, and the sender is requested to retransmit the data packet with the missing sequence number.

[0037] As a preferred technical solution, the following are also included:

[0038] After sending the core business data of collaborative obstacle avoidance to other connected autonomous vehicles within a preset range, the system reports the progress of collaborative obstacle avoidance processing to the cloud platform.

[0039] After triggering the obstacle avoidance operation, the results of the obstacle avoidance operation are reported to the cloud platform.

[0040] As a preferred technical solution, the status information includes the speed, acceleration, and position of other connected vehicle autonomous vehicles.

[0041] Another aspect of the present invention provides a high-information-security collaborative obstacle avoidance system for connected vehicle autonomous driving vehicles, used to implement the aforementioned high-information-security collaborative obstacle avoidance method. The system includes a target vehicle, a roadside unit, an edge intermediate node, and a cloud platform, wherein the target vehicle includes:

[0042] Electronic control unit (ECU) is used to coordinate and control collaborative obstacle avoidance.

[0043] The token generation module is used to generate token information including identity ID, data validity period, and cryptographic signature;

[0044] The sequence number allocation module is used to allocate sequence numbers to the core business data frames of cooperative obstacle avoidance and record the data transmission order;

[0045] The CRC checksum generation module is used to run the CRC-32 algorithm on the collaborative obstacle avoidance core business data frame, generate a fixed 32-bit CRC checksum value, and append it to the end of the data frame to generate a complete data packet.

[0046] The C-V2X communication module is used to send complete data packets to other connected autonomous vehicles within a preset range;

[0047] The vehicle communication log is used to store the data transmission and communication processing records of this vehicle.

[0048] The speed limiting unit is used to implement collaborative obstacle avoidance speed limiting based on the received and verified collaborative obstacle avoidance core business data.

[0049] An alarm unit is used to trigger an alarm for collaborative obstacle avoidance.

[0050] The CRC check verification module is used to obtain the CRC check value Value1 at the end of the data packet. The data packet body is then calculated using CRC-32 to obtain the CRC check value Value2, thus realizing CRC verification.

[0051] The token verification module is used to send a token information verification request to the cloud platform and verify the legitimacy of the initiating vehicle's identity through the cloud platform's pre-set legitimate vehicle identity database.

[0052] The serial number check and verification module is used to verify the serial number of the data frame.

[0053] As a preferred technical solution, the cloud platform includes:

[0054] The cloud server host is used to coordinate and process the cooperative obstacle avoidance function of autonomous vehicles and record the cooperative obstacle avoidance processing results.

[0055] The cloud communication module is used to enable communication with edge intermediate nodes, vehicle-mounted units, and roadside units;

[0056] A legitimate vehicle identity database, including legitimate vehicle information with vehicle identity IDs;

[0057] The vehicle event database is used to store information on the handling of collaborative obstacle avoidance events by connected vehicle autonomous vehicles.

[0058] Compared with the prior art, the present invention has at least the following beneficial effects:

[0059] The collaborative obstacle avoidance key business information of this invention undergoes triple data protection and security hardening processing at the sending end using tokens, serial numbers, and cyclic redundancy check codes. At the receiving end, it undergoes triple linkage verification of cyclic redundancy check code verification, token checking, and serial number verification. This effectively meets the data protection and information security requirements of the key business data transmission process. Through triple linkage verification, the accuracy of the business processing flow of key business information such as collaborative obstacle avoidance of connected vehicle autonomous vehicles is ensured, while effectively avoiding and filtering information security risks of malicious network intrusion, thereby improving the reliability and security of the collaborative obstacle avoidance function of connected vehicle autonomous vehicles. Attached Figure Description

[0060] Figure 1 This is a flowchart of a high-information-security collaborative obstacle avoidance method for connected vehicle autonomous driving in the embodiment.

[0061] Figure 2 This is a system architecture block diagram with information security protection for autonomous driving cooperative obstacle avoidance in the embodiment;

[0062] Figure 3 This is a system composition block diagram of the on-board unit (OBU) of the sending vehicle A in the embodiment;

[0063] Figure 4 This is a system composition block diagram of the on-board OBU of the receiving vehicle B in the embodiment;

[0064] Figure 5 This is a system composition block diagram of the cloud platform C-Svr in the embodiment;

[0065] Figure 6 This is a schematic diagram illustrating the process by which the sending vehicle A generates collaborative obstacle avoidance data information in this embodiment.

[0066] Figure 7 This is a schematic diagram illustrating the process of receiving vehicle B parsing collaborative obstacle avoidance data information in the embodiment.

[0067] Figure 8 This is a schematic diagram of the CRC checksum verification process for the data frame of the receiving vehicle B in the embodiment.

[0068] Figure 9 This is a schematic diagram of the token verification process for the data frame of the receiving vehicle B in the embodiment.

[0069] Figure 10 This is a schematic diagram of the data frame sequence number verification process for the receiving vehicle B in the embodiment. Detailed Implementation

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

[0071] To address the problems existing in the aforementioned technologies, this embodiment provides a high-information-security collaborative obstacle avoidance method for autonomous vehicles in the vehicle-to-everything (V2X) network. It aims to combine critical business information such as collaborative obstacle avoidance for autonomous vehicles with high security requirements with information security technologies such as token checking, serial number verification, and CRC verification. Utilizing Road Side Units (RSUs) and Multi-access Edge Computing (MECs) as intermediaries, it achieves collaborative obstacle avoidance for autonomous vehicles in the V2X network based on a linked verification mechanism of tokens, serial numbers, and cyclic redundancy check codes, thereby improving the reliability of the collaborative obstacle avoidance function of autonomous vehicles in the V2X network.

[0072] This method is applied to a vehicle-to-everything (V2X) autonomous driving system that includes a target vehicle, roadside units, edge intermediate nodes, and a central server. Upon power-on, each communication node in this system automatically uses the cloud server's clock as its synchronization source. See also... Figure 2 The system includes:

[0073] The target vehicle includes the On Board Unit (OBU) of the intelligent device running on the vehicle. The intelligent device on the vehicle acts as a local client and is responsible for information security processing such as obstacle avoidance data frame processing and token / serial number / CRC check code processing.

[0074] The edge intermediate node (MEC) or roadside unit (RSU) is responsible for receiving global vehicle token model parameters transmitted by the central server, and also for receiving vehicle token verification requests and collaborative obstacle avoidance data processing uploaded by local clients.

[0075] The cloud platform or central server C-Svr is responsible for determining vehicle authentication requests and recording collaborative obstacle avoidance processing records.

[0076] See Figure 3 The diagram shows the system composition of the onboard OBU 10 of vehicle A in this embodiment. The onboard unit (ECU) 101 is the electronic control unit of the onboard OBU of vehicle A, responsible for handling the cooperative obstacle avoidance function of vehicle A. The token generation module 102 is responsible for generating token information for vehicle A, including vehicle A's identity ID, data validity period, and encrypted signature. The serial number allocation module 103 is responsible for allocating serial numbers to the obstacle avoidance data information frames and recording the data transmission order to avoid out-of-order processing later. The CRC checksum generation module 104 is responsible for running the CRC-32 algorithm on the data frame, generating a fixed 32-bit CRC checksum value, and appending it to the end of the data frame to generate a complete data packet. The C-V2X communication module 105 is responsible for sending the complete data packet to notify surrounding vehicles B, C, etc. The vehicle communication logbook 106 is responsible for recording the data transmission communication processing record information of this vehicle. The speed limit unit 107 is responsible for handling the execution function of the vehicle's cooperative obstacle avoidance speed limit command. The alarm unit 108 is responsible for handling the execution function of the vehicle's cooperative obstacle avoidance alarm processing.

[0077] See Figure 4The diagram shows the system composition block diagram of the on-board unit (OBU) 20 of vehicle B in this embodiment. The electronic control unit (ECU) 201 is the electronic control unit of the on-board unit (OBU) of vehicle B, responsible for handling the cooperative obstacle avoidance function of vehicle B. The CRC checksum verification module 202 is responsible for verifying the CRC checksum of the data frame. This module extracts the CRC checksum value at the end of the data packet, re-runs the CRC-32 algorithm on the data frame token, serial number, and core data, and generates a fixed 32-bit CRC checksum value. If the two checksum values ​​match, it means that the data was not corrupted by electromagnetic interference or network packet loss during transmission, and the data frame was received correctly; if they do not match, the data packet is discarded directly and a data corruption message is sent to vehicle A, requesting a retransmission. The token verification module 203 is responsible for submitting a token information verification request for vehicle A to the cloud platform C-Svr. It verifies the legitimacy of vehicle A's identity through the cloud platform's pre-set legitimate vehicle identity database, and the verification result is fed back to the vehicle B token verification module 203. The serial number verification module 204 is responsible for verifying the data frame serial number to avoid out-of-order processing in subsequent steps. The C-V2X communication module 205 is responsible for receiving complete data packets sent by vehicle A. The vehicle communication logbook 206 is responsible for recording the vehicle's data transmission and communication processing information. The speed limit unit 207 is responsible for executing the vehicle's cooperative obstacle avoidance speed limit command. The alarm unit 208 is responsible for executing the vehicle's cooperative obstacle avoidance alarm processing.

[0078] See Figure 5 The diagram shows the system composition of the cloud platform C-Svr30 in this embodiment. The cloud server host 301 is the cloud-based central processor of the vehicle-to-everything (V2X) autonomous driving system, responsible for coordinating and processing the cooperative obstacle avoidance function of autonomous vehicles and recording the cooperative obstacle avoidance processing results. The cloud communication module 302 is responsible for enabling data communication between the cloud platform 30 and edge intermediate nodes, on-board OBU 10, on-board OBU 20, roadside units (RSUs), etc. The legitimate vehicle identity database 303 is a pre-set information database containing vehicle identity ID information for legitimate vehicles. The vehicle event database 304 is responsible for storing V2X autonomous driving vehicle cooperative obstacle avoidance event processing records. Other databases 305 are databases for the cloud platform 30 to store other important business information and system information.

[0079] See Figure 1 The method includes S01-S08, where S01-S02 is data generation, S03-S04 is data transmission, S05-S06 is decision execution, and S07-S08 is result feedback. The specific steps of the method are as follows:

[0080] S01, Vehicle A detects a sudden obstacle ahead and identifies surrounding vehicles.

[0081] Vehicle A detects a sudden obstacle ahead, such as fallen cargo, and identifies vehicles B and C within a 500-meter radius that may encounter the same malfunction. For example, this also includes obtaining the status information of autonomous vehicles B and C, using the currently connected vehicle-to-everything (V2X) autonomous vehicles as a reference, including but not limited to acceleration, speed, direction of travel, and throttle / brake opening. This step can be implemented using existing methods.

[0082] S02, vehicle A generates core business data for collaborative obstacle avoidance and performs triple verification of "token + serial number + CRC" for data protection and security reinforcement.

[0083] Among them, the core business data for collaborative obstacle avoidance is generated based on obstacle location, warning level, and suggested deceleration value.

[0084] In this step, vehicle A's security chip or token generation module first generates a token containing vehicle A's unique identifier, a 24-hour data validity period starting at 00:00 on the current day, and an encrypted signature. This token is attached to the header of the collaborative obstacle avoidance warning data to ensure data source traceability. Simultaneously, a sequence number is assigned to this data frame. In this embodiment, for example, "2025100515300001" can be used, where the first 12 bits are a timestamp, and the last 4 bits are an incrementing sequence number for this type of data on that day, recording the data transmission order to avoid out-of-order processing later. After integrating the data content, token, and sequence number, vehicle A runs a CRC-32 algorithm on the entire data frame, including the header token, sequence number, core data, and reserved bits at the end, generating a fixed 32-bit CRC checksum. This CRC checksum is then appended to the end of the data frame, forming a complete data packet containing the token, sequence number, core data, and CRC checksum. This packet is then sent to vehicle B via a V2V communication module, such as C-V2X.

[0085] S03, vehicle A sends a complete data packet via the C-V2X communication module to notify surrounding vehicles B, C, etc.

[0086] Specifically, vehicle A notifies vehicles B, C, etc., within the coverage area of ​​the surrounding edge intermediate node MEC that may encounter the same fault.

[0087] S04, Vehicle A reports to the cloud platform C-Svr via the Roadside Unit (RSU) or the Edge Intermediate Node (MEC).

[0088] S05, Vehicle B parses the core business data of cooperative obstacle avoidance and performs "CRC verification", "token verification" and "serial number verification" of the data frame in sequence.

[0089] After vehicle B receives the complete data packet sent by vehicle A, it will:

[0090] 1) Prioritize CRC check to verify data packet integrity, extract the CRC check value from the end of the data packet, and simultaneously re-run the CRC-32 algorithm on the token, sequence number, and core data. If the two calculation results match, it indicates that the data transmission was not affected by electromagnetic interference or network packet loss, and proceed to the next verification stage; if they do not match, discard the data packet directly and send a data corruption request to vehicle A.

[0091] 2) Token Verification: Vehicle A's identity is verified. Vehicle B's onboard electronic control unit (ECU) requests the token identity information from the cloud platform C-Svr. The cloud platform C-Svr decrypts Vehicle A's token identity using a pre-set database of legitimate vehicle identities, primarily verifying two points: ① Whether the sender is a registered and legitimate vehicle, excluding counterfeit or falsely flagged vehicles; ② Whether the token is within its validity period (within 24 hours starting at 00:00 on the current day), thus preventing hackers from intercepting old tokens and resending them. Successful verification confirms the data source is legitimate.

[0092] 3) Sequence number verification: Verify the transmission order of data frames from vehicle A. Vehicle B queries the local storage for the largest sequence number of recently transmitted data from vehicle A. For example, if the previously received sequence number was "2024052015300000", compare it with the current data packet's sequence number "2024052015300001".

[0093] If the current sequence number equals the previous maximum sequence number plus 1, it means the data is continuous, there are no dropped frames, and the core data can be parsed normally.

[0094] If the current sequence number is less than the previous maximum sequence number + 1, it is considered a duplicate data and is discarded directly (to avoid repeatedly executing obstacle avoidance commands).

[0095] If the current sequence number is greater than the previous maximum sequence number + 1, it is determined to be a lost frame, and vehicle A is immediately requested to retransmit the data packet with the missing sequence number.

[0096] Only when all three checks—CRC verification, token verification, and serial number verification—pass will the Electronic Control Unit (ECU) of vehicle B parse the core data, combine it with its current speed and location, and generate obstacle avoidance commands to decelerate to 30 km / h and activate hazard lights, thus controlling the vehicle to perform the operation. If any verification fails, the data will be intercepted, and no action will be triggered to avoid safety accidents caused by invalid / malicious data.

[0097] S06. After the triple linkage verification is passed, the electronic control unit of vehicle B executes automatic obstacle avoidance processing based on the collaborative obstacle avoidance data information verified by CRC, token and serial number.

[0098] Specifically, after vehicle B passes the triple linkage verification of the data frame, the electronic control unit ECU201 of vehicle B performs automatic obstacle avoidance processing through the speed limit unit 207 and the alarm unit (208) based on the collaborative obstacle avoidance data information sent by vehicle A.

[0099] S07, Vehicle B reports obstacle avoidance operations to the cloud platform C-Svr via the Roadside Unit (RSU) or the Edge Intermediate Node (MEC).

[0100] S08, when vehicle B passes an obstacle, if the obstacle is detected, it continues to send warning information to surrounding vehicles.

[0101] See Figure 6 The diagram shown illustrates the flowchart for vehicle A generating collaborative obstacle avoidance data in this embodiment. Vehicle A generates core collaborative obstacle avoidance business data and performs triple verification using tokens, serial numbers, and CRC for data protection and security hardening, generating a complete data packet for the core collaborative obstacle avoidance business. The detailed process is as follows:

[0102] AS01, Vehicle A detected a sudden obstacle ahead and identified surrounding vehicles B and C.

[0103] AS02, Vehicle A generates cooperative obstacle avoidance data, such as: "obstacle location + warning level + suggested deceleration value".

[0104] AS03, Vehicle A's security chip or token generation module generates a token, which is added to the obstacle avoidance data information frame, such as: "Vehicle A's unique identity ID + data validity period + encrypted signature". The token information is attached to the header of the collaborative obstacle avoidance warning data to ensure the traceability of the data source.

[0105] AS04, Vehicle A is assigned a sequence number for the obstacle avoidance data information frame. This sequence number records the data transmission order to prevent out-of-order processing later. For example, "2025100515300001" represents the sequence number. The first 12 digits are the timestamp, and the last 4 digits are the incrementing sequence number of this type of data for that day. Recording the data transmission order prevents out-of-order processing later.

[0106] AS05, Vehicle A runs the CRC-32 algorithm on the data frame, generates a fixed 32-bit CRC checksum, and appends it to the end of the data frame to generate a complete data packet. Data frame: header token + sequence number + middle core data + tail reserved bits; complete data packet: token + sequence number + core business data + CRC checksum.

[0107] Specifically, vehicle A generates a CRC checksum and a complete data packet. After integrating the data content, token, and sequence number, vehicle A runs the CRC-32 algorithm on the entire data frame, including the header token, sequence number, middle core data, and tail reserved bits, to generate a fixed 32-bit CRC checksum value, which is then appended to the end of the data frame to form a complete data packet containing the token, sequence number, core data, and CRC checksum value. This data packet is then sent to vehicle B via the V2V communication module.

[0108] like Figure 7 The diagram shown is a flowchart of the process for analyzing collaborative obstacle avoidance data information for vehicle B in this embodiment.

[0109] After receiving the cooperative obstacle avoidance data packet from vehicle A, vehicle B sequentially performs CRC verification, token verification, and sequence number verification on the data frame. The detailed process is as follows:

[0110] BS01, Vehicle B received the complete cooperative obstacle avoidance data packet sent by Vehicle A. Data frame: header token + sequence number + middle core data + tail reserved bits; complete data packet: token + sequence number + core business data + CRC check value.

[0111] BS02, Vehicle B parses the data frame from the data packet.

[0112] BS03, Vehicle B performs CRC checksum verification on the data frame. CRC checksum verifies the "integrity" of the data packet.

[0113] BS04, Vehicle B data frame token verification. The token verifies the "legitimacy" of the vehicle's identity. It also checks the time validity and signature validity of the data frame, thereby authenticating vehicle A.

[0114] BS05, Vehicle B Data Frame Sequence Number Verification. The sequence number check verifies the "sequentiality" of the data frames. It checks the order in which collaborative obstacle avoidance data services are processed, preventing missed or duplicate data frames, thus achieving data frame service sequence verification.

[0115] BS06, the collaborative obstacle avoidance data information that has passed the verification of CRC checksum, token, and serial number, will trigger vehicle B to perform obstacle avoidance operations. Vehicle B will perform automatic obstacle avoidance operations, such as generating obstacle avoidance commands to decelerate to 30km / h and activate hazard lights based on its current speed and position, and reporting to the cloud platform.

[0116] See Figure 8 The diagram shown is a flowchart of the CRC checksum verification process for vehicle B data frame in this embodiment.

[0117] Vehicle B extracts the CRC checksum from the end of the data packet and performs a CRC-32 algorithm on the data frame token, sequence number, and core data to determine if the CRC calculation results are consistent. If yes, the data packet is correct, and Vehicle B sends a "Data correct" response message to Vehicle A. If no, the data packet is incorrect, Vehicle B discards the data packet and sends a "Data corrupted, request retransmission" message to Vehicle A.

[0118] Specifically, vehicle B's CRC verification module 202 extracts the CRC checksum Value1 from the end of the data packet and simultaneously re-runs the CRC-32 algorithm on the token, sequence number, and core data to obtain the CRC checksum Value2. If the two calculation results match, it indicates that the data transmission was not affected by electromagnetic interference or network packet loss, and the process proceeds to the next verification stage. If they do not match, the data packet is discarded, and a "data corrupted, request retransmission" command is sent to vehicle A.

[0119] See Figure 9 The diagram shown is a flowchart of the token verification process for vehicle B data frame in this embodiment, which verifies the legitimacy of vehicle A's identity ID.

[0120] Vehicle B's data frame token verification involves extracting Vehicle A's token information from the data frame header. Vehicle B then requests Vehicle A's identity ID from the cloud platform C-Svr via the edge intermediate node MEC. The cloud platform retrieves Vehicle A's identity ID from a pre-built "legitimate vehicle identity database" and sends it to Vehicle B. Vehicle B compares Vehicle A's identity ID in the token with that on the cloud platform to verify Vehicle A's legitimacy. If Vehicle A's identity is legitimate, the process continues; otherwise, if not, the data frame is discarded, and a "Vehicle A's identity is invalid" message is sent to the cloud platform, reporting the anomaly.

[0121] Specifically, the vehicle B's onboard electronic control unit (ECU201) requests the token identity information of vehicle A from the cloud server host 301 of the cloud platform C-Svr30. The cloud server host 301 of the cloud platform C-Svr30 decrypts the token identity of vehicle A through a pre-set legitimate vehicle identity database 303, primarily verifying two points: 1. Whether the sender is a registered and legitimate vehicle, excluding counterfeit vehicles issuing false warnings. 2. Whether the token is valid, preventing hackers from intercepting old tokens and resending them. If the verification is successful, the data source is confirmed to be legitimate. If the token verification is successful, the data frame is valid, and subsequent processing continues. If the verification fails, the data frame is discarded, and the abnormal event is reported to the cloud service host 301 of the cloud platform 30.

[0122] See Figure 10The diagram shows the flowchart for verifying the sequence number of vehicle B's data frames in this embodiment, which verifies the transmission order of vehicle A's data frames. The process is as follows: Vehicle B extracts the vehicle A's sequence number information from the data frame header, copies the current sequence number to Snbr_Curr, and queries the locally stored "maximum sequence number of recently transmitted data from vehicle A" Snbr_Prev. It compares Snbr_Curr with Snbr_Prev + 1. If Snbr_Curr is greater, it's determined that the data frame is lost, and vehicle A is immediately requested to retransmit the data packet with the missing sequence number. If Snbr_Curr is equal, there is no lost frame, and normal processing is performed, updating the sequence number information of the data packets transmitted by vehicle A. If Snbr_Curr is less than Snbr_Prev, the data frame is determined to be duplicated and discarded to avoid repeatedly executing obstacle avoidance commands.

[0123] Vehicle B queries the local vehicle communication record database 206 for the maximum sequence number Snbr_Prev of the most recently sent data from Vehicle A, and compares it with the sequence number Snbr_Curr of the current data packet:

[0124] If the current sequence number equals the previous maximum sequence number plus 1, it indicates that the data is continuous, there are no dropped frames, and the core data can be parsed normally.

[0125] If the current sequence number is less than the previous maximum sequence number + 1, it is considered a duplicate data and is discarded to avoid repeatedly executing obstacle avoidance commands.

[0126] If the current sequence number is greater than the previous maximum sequence number + 1, it is determined to be a lost frame, and vehicle A is immediately requested to retransmit the data packet with the missing sequence number.

[0127] when Figure 8 , Figure 9 , Figure 10 If all three verifications shown—CRC checksum, token, and serial number—pass, the ECU (Electronic Control Unit) 201 of vehicle B will parse the core data, combine it with its current speed and location, generate an obstacle avoidance command to decelerate to 30 km / h and activate hazard lights, and control the vehicle to perform the operation. If any verification fails, the data will be intercepted and no action will be triggered to avoid safety accidents caused by invalid / malicious data.

[0128] The collaborative obstacle avoidance key business information of this invention undergoes triple data protection and security hardening processing at the sending end using tokens, serial numbers, and cyclic redundancy check codes; at the receiving end, it undergoes triple linkage verification of cyclic redundancy check code verification, token checking, and serial number verification, effectively meeting the data protection and information security requirements of the key business data transmission process; the triple linkage verification also ensures the business processing flow of key business information such as collaborative obstacle avoidance, improving the reliability and security of the collaborative obstacle avoidance function of vehicle-to-everything (V2X) autonomous vehicles.

[0129] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and these modifications or substitutions should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A collaborative obstacle avoidance method with high information security for connected vehicle autonomous driving vehicles, characterized in that, Includes the following steps: In response to the detection of a sudden obstacle, the system obtains the status information of other connected autonomous vehicles within a preset range, using the current connected autonomous vehicle as a reference, and generates collaborative obstacle avoidance warning data, including obstacle location, warning level, and suggested deceleration value. Based on the collaborative obstacle avoidance early warning data, core business data for collaborative obstacle avoidance is generated through token, serial number and CRC processing. The core business data of collaborative obstacle avoidance is sent to other connected autonomous vehicles within a preset range; Upon receiving the core business data for collaborative obstacle avoidance, verification is performed sequentially using CRC, token, and sequence number checks. Upon successful verification, obstacle avoidance is triggered. The token, serial number, and CRC processing includes the following steps: Based on the unique identifier, data validity period and cryptographic signature of the current connected vehicle autonomous driving vehicle, a token is generated and added to the header of the collaborative obstacle avoidance warning data; Assign a sequence number to the current data frame based on the timestamp and the sequence number of data of the same type; By integrating the token, collaborative obstacle avoidance early warning data, and serial number, a CRC checksum is generated, forming the core business data for collaborative obstacle avoidance. The process of sequentially performing CRC, token, and serial number verification includes the following steps: Receive core business data on collaborative obstacle avoidance sent by other connected vehicle autonomous vehicles; Data frames are obtained by parsing the core business data of the collaborative obstacle avoidance; Perform CRC check on the data frame to verify the integrity of the data packet; The data is subjected to frame token verification to check the validity of the sender's identity ID, as well as the time validity and signature validity of the data frame, thereby realizing the sender's identity verification. Based on the data frame, the sequence number is verified to confirm the order of the data frame and check the order of collaborative obstacle avoidance data service processing, thereby realizing the service order verification of the data frame.

2. The high-information-security collaborative obstacle avoidance method for autonomous vehicles connected to the Internet of Vehicles as described in claim 1, characterized in that, The CRC verification process includes the following steps: Extract the first CRC check value from the tail of the collaborative obstacle avoidance core business data, and obtain the second CRC check value through the CRC-32 algorithm; Determine whether the first CRC check value is equal to the second CRC check value. If yes, proceed to the next verification step; otherwise, discard the data packet and send a retransmission command to the sender.

3. The high-information-security collaborative obstacle avoidance method for autonomous vehicles connected to the Internet of Vehicles as described in claim 1, characterized in that, The frame token verification process includes the following steps: The system requests the sender's token identity information from the cloud platform. After verifying whether the token has been registered and is within its validity period on the cloud platform, the system obtains the verification result from the cloud platform. If the verification is successful, the data frame is valid and subsequent processing continues. If the verification fails, the data frame is discarded and an anomaly is reported to the cloud platform.

4. A high-information-security collaborative obstacle avoidance method for autonomous vehicles connected to the Internet of Vehicles according to claim 1, characterized in that, The serial number verification process includes the following steps: Query the maximum sequence number of the data sent by the sender in the local storage and compare it with the sequence number of the current data packet: If the current sequence number equals the previous maximum sequence number plus 1, then the verification passes. If the current sequence number is less than the previous maximum sequence number + 1, it is considered a duplicate data and is discarded. If the current sequence number is greater than the previous maximum sequence number + 1, it is determined to be a lost frame, and the sender is requested to retransmit the data packet with the missing sequence number.

5. A high-information-security collaborative obstacle avoidance method for autonomous vehicles connected to the Internet of Vehicles according to claim 1, characterized in that, Also includes: After sending the core business data of collaborative obstacle avoidance to other connected autonomous vehicles within a preset range, the system reports the progress of collaborative obstacle avoidance processing to the cloud platform. After triggering the obstacle avoidance operation, the results of the obstacle avoidance operation are reported to the cloud platform.

6. A high-information-security collaborative obstacle avoidance method for autonomous vehicles connected to the Internet of Vehicles according to claim 1, characterized in that, The status information includes the speed, acceleration, and location of other connected autonomous vehicles.

7. A high-information-security collaborative obstacle avoidance system for connected vehicle autonomous driving vehicles, characterized in that, To implement the high information security collaborative obstacle avoidance method as described in any one of claims 1-6, the system includes a target vehicle, a roadside unit, an edge intermediate node, and a cloud platform, wherein the target vehicle includes: Electronic control unit (ECU) is used to coordinate and control collaborative obstacle avoidance. The token generation module is used to generate token information including identity ID, data validity period, and cryptographic signature; The sequence number allocation module is used to allocate sequence numbers to the core business data frames of cooperative obstacle avoidance and record the data transmission order; The CRC checksum generation module is used to run the CRC-32 algorithm on the collaborative obstacle avoidance core business data frame, generate a fixed 32-bit CRC checksum value, and append it to the end of the data frame to generate a complete data packet. The C-V2X communication module is used to send complete data packets to other connected autonomous vehicles within a preset range; The vehicle communication log is used to store the data transmission and communication processing records of this vehicle. The speed limiting unit is used to implement collaborative obstacle avoidance speed limiting based on the received and verified collaborative obstacle avoidance core business data. An alarm unit is used to trigger an alarm for collaborative obstacle avoidance. The CRC check verification module is used to obtain the CRC check value Value1 at the end of the data packet. The data packet body is then calculated using CRC-32 to obtain the CRC check value Value2, thus realizing CRC verification. The token verification module is used to send a token information verification request to the cloud platform and verify the legitimacy of the initiating vehicle's identity through the cloud platform's pre-set legitimate vehicle identity database. The serial number check and verification module is used to verify the serial number of the data frame.

8. A high-information-security collaborative obstacle avoidance system for connected vehicle autonomous driving vehicles according to claim 7, characterized in that, The cloud platform mentioned includes: The cloud server host is used to coordinate and process the cooperative obstacle avoidance function of autonomous vehicles and record the cooperative obstacle avoidance processing results. The cloud communication module is used to enable communication with edge intermediate nodes, vehicle-mounted units, and roadside units; A legitimate vehicle identity database, including legitimate vehicle information with vehicle identity IDs; The vehicle event database is used to store information on the handling of collaborative obstacle avoidance events by connected vehicle autonomous vehicles.

Images