Driving data processing method and device based on alliance chain

Abstract

The application relates to the technical field of blockchains, and discloses a driving data processing method and device based on a consortium chain. The driving data processing method comprises the following steps: in response to a reporting instruction of a user node, acquiring timestamp information of the reporting instruction, and generating first encrypted information with timestamps based on vehicle key data; a node acquires a plurality of first encrypted information, classifies the plurality of first encrypted information according to time nodes and packs the first encrypted information into blocks according to the permissions assigned according to the type of the node, and stores the first encrypted information; when receiving an extraction instruction of a certain node, extracting time information in the extraction instruction, and extracting a corresponding storage block according to the time information. The driving data management method improves data reliability.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and in particular to a method and apparatus for processing vehicle data based on a consortium blockchain. Background Technology

[0002] With the rapid development of intelligent connected vehicles and vehicle-to-everything (V2X) technology, the reliability of driving data has become a core requirement for scenarios such as autonomous driving safety, liability determination, and V2X insurance pricing. Traditional driving data management relies on centralized storage systems (such as onboard ECUs and cloud databases), which suffer from problems such as data being easily tampered with, single-point failures leading to data loss, and difficulty in verifying the credibility of multi-source data.

[0003] The reliability of driving data is a crucial issue in its use; therefore, improving the reliability of driving data is a technical problem that needs to be solved. Summary of the Invention

[0004] This application provides a method and apparatus for processing vehicle data based on a consortium blockchain, which improves the reliability of vehicle data.

[0005] To achieve the above objectives, the main technical solutions adopted in this application include:

[0006] In a first aspect, embodiments of this application provide a vehicle data processing method based on a consortium blockchain, comprising the following steps:

[0007] In response to the reporting command from the user node, the timestamp information of the reporting command is obtained, and the first encrypted information with the timestamp is generated based on the key vehicle data;

[0008] Each node acquires multiple first-level encrypted messages, and based on the permissions assigned according to the node type, categorizes and packages these messages into blocks according to their time nodes, and then stores them.

[0009] When a fetch instruction is received from a node, the time information in the fetch instruction is extracted, and the corresponding storage block is extracted based on the time information.

[0010] This application proposes a vehicle data processing method based on a consortium blockchain. Through the distributed architecture of the consortium blockchain, it enables collaborative participation from multiple nodes, including users, regulators, and enterprises, solving the data silo and trust barrier problems inherent in traditional centralized storage models. This ensures transparency and trustworthiness throughout the entire data collection, storage, and sharing process. Specifically, after a user node triggers a reporting command, the system collects key data in real time, including collision images, vehicle speed, and GPS trajectory. Multi-device verification, dynamic threshold filtering, and multi-level hash encryption technologies ensure the authenticity and integrity of the data. Consortium blockchain nodes classify and store data based on role-based access control (RBAC model), and an improved PBFT consensus mechanism guarantees the trustworthiness of data blocks, avoiding the risk of tampering by a single node and further improving data reliability.

[0011] Optionally, generating the first encrypted information based on key vehicle data includes:

[0012] Collect raw data from multiple devices and perform cross-verification;

[0013] When the data difference within the same time window is less than the dynamic threshold, the data is retained and a feature tree is generated. The dynamic threshold is calculated based on real-time environmental parameters.

[0014] Based on timestamp information, multi-level hash values ​​are generated step by step from the feature tree. The multi-level hash values ​​include the original data hash, cross-device fusion hash, and timestamp hash, which are combined to form the first encrypted information.

[0015] In the above scheme, the method of generating the first encrypted information based on key vehicle data significantly improves the reliability and security of data processing through multi-dimensional technical design: First, by using a sliding window to compare data differences in real time, abnormal data caused by single device failure or human tampering is effectively filtered out, ensuring the authenticity of data from the source; Second, a dynamic threshold algorithm combined with real-time environmental parameters (such as location information and meteorological data) intelligently adjusts the data filtering criteria to avoid misjudgment caused by environmental interference and improve the environmental adaptability of data collection; Third, by constructing a multi-level feature tree containing original data hash, cross-device fusion hash, and timestamp hash, a chain-like encryption structure is formed, and the timestamp ensures that the data time sequence cannot be tampered with, further improving data reliability.

[0016] Optionally, after obtaining multiple initial encrypted messages, the node performs the following steps:

[0017] The header hash value is extracted from multiple first encrypted messages using the public key of the supervisory node, and the signature validity of the header hash value is verified.

[0018] In the above scheme, the public key system of the regulatory node is used to verify the header hash value to ensure the legitimacy of the data source. Only data blocks signed by the private key of the regulatory node can be identified as valid, preventing forged data from being mixed into the consortium blockchain and eliminating the risk of "data fraud" from the source. The signature validity verification mechanism and the consortium blockchain consensus mechanism form a dual verification: the regulatory node participates in the verification as an authoritative institution and forms a cross-verification network with other consensus nodes (such as car manufacturers and insurance companies). Only when more than a preset number of nodes confirm the validity of the signature will the data block be marked as a trusted unit, further improving data reliability.

[0019] Optionally, after verifying the signature validity of the header hash value, perform the following steps:

[0020] Once more than a preset number of nodes have verified the signature as valid, the corresponding storage block is marked as a trusted storage unit, and an accident reconstruction model is generated based on the original data. The accident reconstruction model is then bound to the hash value of the original data for storage.

[0021] In the above scheme, hash binding technology ensures a strong correlation between the model and the data. Any tampering will trigger a verification anomaly, strengthening the immutability of the data. After multiple nodes verify the validity of the signature, the system automatically extracts the multi-level hash values ​​of the original data (such as sensor data hash, timestamp hash, and cross-device fusion hash) and embeds these hash values ​​as digital anchors for model parameters into the accident reconstruction model. Any minor modification to the original data (such as adjusting the collision time or forging braking records) will cause the hash values ​​to change abruptly, thus causing the model verification to fail, thereby further improving the reliability of the data.

[0022] Optionally, after verifying the signature validity of the header hash value, perform the following steps:

[0023] A hash tree is generated based on the verified trusted data units and their corresponding timestamp information. A unique block containing the vehicle identifier and consensus node signature is then generated based on the hash tree.

[0024] In the above scheme, a Merkle tree structure is used to associate timestamps with key data through layer-by-layer hashing. Any single data tampering will cause the root hash value to change. At the same time, the layered verification mechanism of the hash tree compresses the traditional full data comparison into root hash value verification, which significantly improves verification efficiency. The unique binding of vehicle identifiers to blocks ensures that the data source can be accurately traced. Combined with the continuity verification of timestamps, the risk of data backtracking and forgery is further reduced, thereby improving data reliability.

[0025] Optionally, after retrieving the corresponding storage block based on the time information, perform the following steps:

[0026] Determine the permission type of the node that issued the extraction command, and verify the access legitimacy according to the preset permission rules.

[0027] In the above solution, data access is strictly limited to the authorized scope by preset permission rules, which builds a refined data protection system, significantly improves the security and compliance of data use, reduces the risk of unauthorized access, ensures that only nodes with legitimate qualifications can obtain the corresponding data, avoids unverified third-party nodes from reading or tampering with data, and eliminates interference from "untrusted entities" from the source of access.

[0028] Optionally, verifying access legitimacy based on preset permission rules includes:

[0029] Determine whether the node issuing the extraction command has a supervisory node permission type. If so, increase the initial permission level of the extraction command; otherwise, decrease the initial permission level of the extraction command.

[0030] In the above scheme, by implementing a dynamic permission level upgrade mechanism for regulatory nodes, an authoritative and reliable data access channel is built to ensure data reliability: the system prioritizes verifying the permission type of regulatory nodes and upgrades their access level, ensuring that in scenarios such as security supervision and accident investigation, regulatory nodes can quickly obtain the original data and complete hash chain information without anonymization, avoiding accidental deletion or tampering of data during the anonymization or permission filtering process, and ensuring the integrity of the evidence chain from the source; the permission downgrade mechanism for non-regulatory nodes, through rules such as limiting access fields and mandatory anonymization, prevents low-privilege subjects from accessing core data, thereby helping to improve data reliability.

[0031] Optionally, generating the first encrypted information with a timestamp based on key vehicle data includes:

[0032] Acquire driving data from multiple devices, including a first device and a second device. Collect driving data from the first device and the second device. Verify the driving data from the first device and the second device. If the verification is true, proceed to the next step; otherwise, discard the driving data from both devices.

[0033] In the above scheme, by collecting driving data from multiple devices and implementing a cross-verification mechanism, the reliability and availability of data are significantly improved: the system simultaneously acquires synchronous data from a first device (such as an in-vehicle camera) and a second device (such as an IMU inertial measurement unit), and performs cross-verification by aligning timestamps and comparing data features (such as vehicle speed and trajectory coordinates at the same moment). When the difference between the two is within a preset threshold, it is determined that the cross-verification is true, ensuring data consistency; if the cross-verification fails, both types of data are discarded simultaneously to avoid the mixing of erroneous data caused by a single device failure (such as abnormal camera frame rate or sensor offset), thus eliminating "faulty data" from the source. This dual-device cross-verification mechanism constructs a "double insurance" for data quality, further improving data reliability.

[0034] Optionally, cross-verification of driving data from the first device and the second device includes:

[0035] A sliding window is used to cross-validate the original driving data of the first device and the original driving data of the second device. When the difference between the data within the same time window is greater than the threshold, the original driving data of the first device and the original driving data of the second device after a certain time interval are discarded.

[0036] In the above scheme, a sliding window mutual verification mechanism is used to verify the driving data of the two devices, which enhances the accuracy and reliability of the data from multiple dimensions: by defining a fixed time window (such as within 1 second), the raw data of the first device and the second device are compared in real time, which can accurately capture the consistency of data within the same time period and avoid misjudgment caused by time misalignment; when the data difference within the window exceeds the threshold, not only is the current data discarded, but the data of the second device after a certain time interval is also removed. This is because sensor failures or external interference are often persistent, and clearing related data can effectively cut off the abnormal data chain and prevent "contamination" of subsequent collection content; this mechanism effectively copes with sudden interference in complex scenarios.

[0037] Secondly, embodiments of this application propose a vehicle data processing device based on a consortium blockchain, applicable to the vehicle data management method as described in any of the above embodiments, including:

[0038] The data acquisition layer includes mobile devices, which collect and upload data in real time.

[0039] The node layer includes regulatory nodes, consensus nodes, and user nodes. At least one of the regulatory nodes, consensus nodes, and user nodes can upload to or access the consortium blockchain.

[0040] The second aspect of this application proposes a vehicle data processing device based on a consortium blockchain. Through a layered architecture and multi-node collaborative design, it brings significant advantages to the full lifecycle management of vehicle data: the mobile device in the data acquisition layer adopts multi-sensor fusion technology to collect key vehicle data in real time and complete preprocessing and mutual verification at the edge, ensuring the authenticity and accuracy of the data uploaded to the blockchain; the management node, with its high-privilege configuration, enables real-time auditing and compliance supervision of the entire data, effectively curbing the risk of data tampering; the consensus node performs distributed verification of data blocks based on an improved PBFT algorithm, and only after more than a preset number of nodes confirm the data is it marked as trustworthy, ensuring the immutability of data storage; the user node grants vehicle owners autonomous control over their data, allowing them to flexibly authorize the scope of data access, avoiding privacy leaks and helping to improve data reliability. Attached Figure Description

[0041] To more clearly illustrate the technical solutions in the specific embodiments of this application or the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0042] Figure 1 This is a schematic diagram of the vehicle data processing method steps in some embodiments of this application;

[0043] Figure 2 This is a schematic diagram of the driving data processing method steps in some other embodiments of this application;

[0044] Figure 3 This is a schematic diagram of the driving data processing method steps in some other embodiments of this application;

[0045] Figure 4 This is a schematic diagram of the driving data processing method steps in some other embodiments of this application;

[0046] Figure 5 This is a block diagram of a vehicle data processing device in some embodiments of this application.

[0047] [Explanation of Labels in the Attached Image]

[0048] 1000: Data Acquisition Layer;

[0049] 100: Mobile devices;

[0050] 2000: Node layer;

[0051] 200: Regulatory node;

[0052] 300: Consensus Node;

[0053] 400: User Node. Detailed Implementation

[0054] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0055] Unless otherwise defined, all technical and scientific terms used in this application have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains; the terminology used in the description of this application is for the purpose of describing particular embodiments only and is not intended to limit the application; the terms "comprising" and "having," and any variations thereof, in the description, claims, and accompanying drawings of this application are intended to cover non-exclusive inclusion. The terms "first," "second," etc., in the description, claims, or accompanying drawings of this application are used to distinguish different objects, not to describe a specific order or hierarchy.

[0056] In this application, the reference to "embodiment" means that a specific feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a mutually exclusive, independent, or alternative embodiment. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described in this application can be combined with other embodiments.

[0057] In the description of this application, it should be noted that, unless otherwise expressly specified and limited, the terms "installation," "connection," "linking," and "attachment" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal communication between two components. Those skilled in the art can understand the specific meaning of the above terms in this application according to the specific circumstances.

[0058] In this application, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, in this application, the character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0059] In this application, "multiple" refers to two or more (including two), and similarly, "multiple groups" refers to two or more (including two), and "multiple pieces" refers to two or more (including two).

[0060] With the rapid development of intelligent connected vehicles and vehicle-to-everything (V2X) technology, the reliability of driving data has become a core requirement in scenarios such as autonomous driving safety, traffic accident liability determination, and V2X insurance pricing. Traditional driving data management relies on centralized storage systems (such as onboard ECUs and cloud databases), which suffer from problems such as data being easily tampered with, single-point failures leading to data loss, and difficulty in verifying the credibility of multi-source data. For example, in traffic accidents, centrally stored sensor data may be distorted due to human intervention or hardware failure, making it difficult to use as credible evidence; if the multi-sensor data relied upon by autonomous driving systems has timing deviations or is at risk of being forged, it may lead to decision-making errors or even safety accidents.

[0061] Furthermore, existing data verification mechanisms are mostly based on fixed rules, which cannot dynamically adapt to the interference of complex environments (such as weather changes and road conditions), leading to a high false positive rate. Meanwhile, the computing power and storage resources of in-vehicle terminals are limited, and traditional methods of uploading all data to the blockchain can easily cause excessive system load, making it difficult to meet real-time requirements. How to achieve efficient collection, reliable storage, and flexible application of driving data while ensuring data integrity, availability, and privacy security has become a key challenge for the application of blockchain technology in the field of connected vehicles.

[0062] During the use of driving data, lengthy accident handling cycles lead to inefficient liability determination; the flow of driving data suffers from a lack of transparency and a crisis of trust; cross-industry data collaboration faces systemic barriers; and these issues continue to constrain vehicle transactions, enterprise service upgrades, and digital supervision.

[0063] Therefore, the lack of reliability of driving data is a technical problem that urgently needs to be solved.

[0064] In view of this, in order to improve the reliability of driving data, this application provides a driving data processing method based on consortium blockchain, which improves the reliability of driving data.

[0065] The following is in conjunction with the appendix Figure 1 -Appendix Figure 4 This application provides a specific embodiment of a vehicle data processing method based on a consortium blockchain.

[0066] This application provides a vehicle data processing method based on a consortium blockchain, including the following steps:

[0067] S1. In response to the user node's reporting command, obtain the timestamp information of the reporting command and generate the first encrypted information with the timestamp based on the vehicle's key data. It can be understood that by accurately recording the reporting time in the encrypted information, a "time fingerprint" of the data is formed. Any subsequent tampering attempts will result in a mismatch between the timestamp and the data hash value, significantly improving data credibility. For example, in accident tracing, a precise timestamp can reconstruct a millisecond-level event sequence, providing crucial evidence for liability determination.

[0068] S2. The node obtains multiple first-level encrypted information, classifies and packages these multiple first-level encrypted information into blocks according to the permissions assigned to the node type, and stores them. It can be understood that different types of nodes (supervisory nodes, consensus nodes, user nodes) can only access a subset of data within their permission scope, which not only improves data reliability but also reduces the risk of data abuse.

[0069] S3. Upon receiving a retrieval command from a node, extract the time information from the command and retrieve the corresponding storage block based on that time information. It's understood that all nodes store and retrieve data based on the same time rules, ensuring data consistency during the transfer process. For example, when multiple nodes simultaneously query data from the same time period, the returned hash values ​​are completely identical, effectively avoiding disputes caused by data discrepancies.

[0070] This application proposes a vehicle data processing method based on a consortium blockchain. Through the distributed architecture of the consortium blockchain, it enables collaborative participation from multiple nodes, including users, regulators, and enterprises, solving the data silo and trust barrier problems inherent in traditional centralized storage models. This ensures transparency and trustworthiness throughout the entire data collection, storage, and sharing process. Specifically, after a user node triggers a reporting command, the system collects key data in real time, including collision images, vehicle speed, and GPS trajectory. Multi-device verification, dynamic threshold filtering, and multi-level hash encryption technologies ensure the authenticity and integrity of the data. Consortium blockchain nodes classify and store data based on role-based access control (RBAC model), and an improved PBFT consensus mechanism guarantees the trustworthiness of data blocks, avoiding the risk of tampering by a single node and further improving data reliability.

[0071] In other embodiments, generating the first encrypted information based on key vehicle data includes:

[0072] S101. Collect raw data from multiple devices and perform cross-verification;

[0073] S102. When the data difference within the same time window is less than the dynamic threshold, the data is retained and a feature tree is generated. The dynamic threshold is calculated based on real-time environmental parameters.

[0074] S103. Based on the timestamp information, multi-level hash values ​​are generated step by step from the feature tree. The multi-level hash values ​​include the original data hash, cross-device fusion hash and timestamp hash, which are combined to form the first encrypted information.

[0075] By collecting raw data from multiple devices such as vehicle-mounted cameras, IMU sensors, and CAN bus modules and performing cross-verification, the system uses a sliding window cross-verification mechanism to compare multi-source data in real time, effectively eliminating erroneous data caused by single device failure or human tampering. For example, when the difference in vehicle speed data between the vehicle-mounted camera and the IMU sensor within the same time window exceeds a dynamic threshold, the system will automatically discard abnormal data, ensuring the accuracy of the data uploaded to the blockchain.

[0076] Dynamic thresholds are dynamically adjusted based on real-time environmental parameters (such as vehicle location information, road surface adhesion coefficient, and meteorological data) to make data filtering rules more closely match actual scenarios. For example, when the road surface is slippery in rainy weather, the system automatically relaxes the allowable threshold for vehicle speed fluctuations to avoid misjudging normal driving behavior due to environmental interference and improve the rationality of data collection.

[0077] A multi-level feature tree containing original data hash, cross-device fused hash, and timestamp hash is generated from the mutually verified data. A chain-like encryption structure is formed through layer-by-layer hash operations. Even if the data on a single device is tampered with, the inconsistency of the cross-device fused hash will immediately expose the anomaly. At the same time, the timestamp hash ensures that the data is stored in order and cannot be modified retroactively, further improving data reliability.

[0078] The feature tree structure performs lightweight processing on the original data, using hash values ​​to replace the original data in on-chain consensus. This significantly reduces on-chain storage pressure while ensuring data integrity. For example, high-frequency sensor data collected per second can have its storage reduced by more than 50% after feature tree compression, while also supporting rapid location and verification, thus improving the processing efficiency of consortium blockchains.

[0079] In the above scheme, the method of generating the first encrypted information based on key vehicle data significantly improves the reliability and security of data processing through multi-dimensional technical design: First, by using a sliding window to compare data differences in real time, abnormal data caused by single device failure or human tampering is effectively filtered out, ensuring the authenticity of data from the source; Second, a dynamic threshold algorithm combined with real-time environmental parameters (such as location information and meteorological data) intelligently adjusts the data filtering criteria to avoid misjudgment caused by environmental interference and improve the environmental adaptability of data collection; Third, by constructing a multi-level feature tree containing original data hash, cross-device fusion hash, and timestamp hash, a chain-like encryption structure is formed, and the timestamp ensures that the data time sequence cannot be tampered with, further improving data reliability.

[0080] In other embodiments, after a node obtains multiple first encrypted pieces of information, it performs the following steps:

[0081] S104. Extract the header hash value from multiple first encrypted messages using the public key of the supervisory node. Understandably, the supervisory node's exclusive public key is used for decryption to ensure that only authorized supervisory entities can verify the data signature, preventing malicious nodes from forging or tampering with encrypted information.

[0082] Verify the signature validity of the header hash value.

[0083] Understandably, a valid signature binds the identity information of the data uploading node, allowing direct tracing back to the source node if data anomalies are subsequently discovered. For example, in autonomous driving accident investigations, signature verification can quickly identify the responsible party that provided erroneous sensor data. Furthermore, pre-verifying signature validity can filter out invalid or malicious data, reducing the processing burden on consensus nodes.

[0084] In the above scheme, the public key system of the regulatory node is used to verify the header hash value to ensure the legitimacy of the data source. Only data blocks signed by the private key of the regulatory node can be identified as valid, preventing forged data from being mixed into the consortium blockchain and eliminating the risk of "data fraud" from the source. The signature validity verification mechanism and the consortium blockchain consensus mechanism form a dual verification: the regulatory node participates in the verification as an authoritative institution and forms a cross-verification network with other consensus nodes (such as car manufacturers and insurance companies). Only when more than a preset number of nodes confirm the validity of the signature will the data block be marked as a trusted unit, further improving data reliability.

[0085] In other embodiments, after verifying the signature validity of the header hash value, the following steps are performed:

[0086] S105. When more than a preset number of nodes verify the validity of the signature, the corresponding storage block is marked as a trusted storage unit, and an accident reconstruction model is generated based on the original data. The accident reconstruction model is then bound to the hash value of the original data for storage.

[0087] Understandably, verifying signature validity independently through multiple nodes (such as supervisory nodes and consensus nodes) avoids the risk of malicious activity from a single node. Only when a preset threshold (such as 2 / 3 of the nodes) confirms validity is the signature marked as trustworthy, making data tampering require compromise of more than half of the nodes simultaneously, thus increasing the attack cost exponentially compared to single-node verification.

[0088] Furthermore, the model is bound one-to-one with the original data hash value. If the model or data is tampered with, the hash values ​​will no longer match, thus significantly improving data reliability.

[0089] In the above scheme, hash binding technology ensures a strong correlation between the model and the data. Any tampering will trigger a verification anomaly, strengthening the immutability of the data. After multiple nodes verify the validity of the signature, the system automatically extracts the multi-level hash values ​​of the original data (such as sensor data hash, timestamp hash, and cross-device fusion hash) and embeds these hash values ​​as digital anchors for model parameters into the accident reconstruction model. Any minor modification to the original data (such as adjusting the collision time or forging braking records) will cause the hash values ​​to change abruptly, thus causing the model verification to fail, thereby further improving the reliability of the data.

[0090] In other embodiments, after verifying the signature validity of the header hash value, the following steps are performed:

[0091] S106. Generate a hash tree based on the verified trusted data unit and its corresponding timestamp information, and generate a unique block containing the vehicle identifier and consensus node signature based on the hash tree.

[0092] The block generates a unique block ID (such as a 32-bit hash value) by combining "vehicle identifier + timestamp + hash tree root value + consensus node signature", ensuring that each block is unique in the consortium blockchain and preventing duplication or forgery.

[0093] Understandably, hash trees and consensus node signatures ensure that data is immutable once it's on the blockchain, and its integrity can be quickly verified via blockchain explorers or node tools. Furthermore, different nodes in a consortium blockchain recognize the validity of the consensus node signature, eliminating the need to repeatedly verify the original data.

[0094] In the above scheme, a Merkle tree structure is used to associate timestamps with key data through layer-by-layer hashing. Any single data tampering will cause the root hash value to change. At the same time, the layered verification mechanism of the hash tree compresses the traditional full data comparison into root hash value verification, which significantly improves verification efficiency. The unique binding of vehicle identifiers to blocks ensures that the data source can be accurately traced. Combined with the continuity verification of timestamps, the risk of data backtracking and forgery is further reduced, thereby improving data reliability.

[0095] In other embodiments, after extracting the corresponding storage block based on the time information, the following steps are performed:

[0096] Determine the permission type of the node that issued the extraction command, and verify the access legitimacy according to the preset permission rules.

[0097] In a specific embodiment, the extraction instruction includes a default permission level. The permission level of the extraction instruction is dynamically changed according to the different node types, thereby further reducing the possibility of data being illegally leaked.

[0098] Among them, the regulatory node: by default has full data access permission and can obtain the original encrypted data and hash chain information;

[0099] Enterprise nodes can only access a subset of anonymized data that is relevant to their business (e.g., car manufacturers can only access data such as vehicle malfunctions, and insurance companies can only access data such as accident claims).

[0100] User nodes can only view anonymized statistical information about personal data (such as trip duration, average fuel consumption, etc.).

[0101] In the above solution, data access is strictly limited to the authorized scope by preset permission rules, which builds a refined data protection system, significantly improves the security and compliance of data use, reduces the risk of unauthorized access, ensures that only nodes with legitimate qualifications can obtain the corresponding data, avoids unverified third-party nodes from reading or tampering with data, and eliminates interference from "untrusted entities" from the source of access.

[0102] In other embodiments, verifying access legitimacy according to preset permission rules includes:

[0103] Determine whether the node issuing the extraction command has a supervisory node permission type. If so, increase the initial permission level of the extraction command; otherwise, decrease the initial permission level of the extraction command.

[0104] Therefore, this setup prioritizes the regulatory node as the guardian of industry compliance. Its elevated privilege level ensures rapid access to full raw data and advanced analysis results (such as un-anonymized collision trajectories and raw sensor waveforms) in scenarios like accident investigations and safety supervision, shortening the time required to extract crucial evidence. For example, in major traffic accidents, the regulatory node can directly access encrypted raw data using its high privilege level.

[0105] Secondly, the permission downgrade mechanism for non-regulatory nodes forms a risk isolation zone, preventing enterprise nodes (such as car manufacturers and insurance companies) from accessing sensitive data beyond their business scope. For example, when an insurance company requests access to accident data, the system automatically limits its permissions to necessary fields such as collision images and vehicle speed, and anonymizes information such as vehicle owner identity and complete trajectory data. While meeting claims requirements, it reduces the risk of user privacy leakage to the lowest industry standard.

[0106] Furthermore, dynamic permission adjustment is deeply integrated with the consensus mechanism of the consortium blockchain. High-permission operations by regulatory nodes require confirmation from at least a certain number of consensus nodes to prevent abuse of permissions.

[0107] In the above scheme, by implementing a dynamic permission level upgrade mechanism for regulatory nodes, an authoritative and reliable data access channel is built to ensure data reliability: the system prioritizes verifying the permission type of regulatory nodes and upgrades their access level, ensuring that in scenarios such as security supervision and accident investigation, regulatory nodes can quickly obtain the original data and complete hash chain information without anonymization, avoiding accidental deletion or tampering of data during the anonymization or permission filtering process, and ensuring the integrity of the evidence chain from the source; the permission downgrade mechanism for non-regulatory nodes, through rules such as limiting access fields and mandatory anonymization, prevents low-privilege subjects from accessing core data, thereby helping to improve data reliability.

[0108] In other embodiments, generating the first timestamped encrypted information based on key vehicle data includes:

[0109] S111. Obtain driving data from multiple devices, including a first device and a second device, and collect driving data from the first device and the second device.

[0110] S112. Verify the driving data of the first device and the driving data of the second device.

[0111] S113. If the mutual verification is true, proceed to the next step; otherwise, discard the driving data of both the first and second devices.

[0112] In the above scheme, by collecting driving data from multiple devices and implementing a cross-verification mechanism, the reliability and availability of data are significantly improved: the system simultaneously acquires synchronous data from a first device (such as an in-vehicle camera) and a second device (such as an IMU inertial measurement unit), and performs cross-verification by aligning timestamps and comparing data features (such as vehicle speed and trajectory coordinates at the same moment). When the difference between the two is within a preset threshold, it is determined that the cross-verification is true, ensuring data consistency; if the cross-verification fails, both types of data are discarded simultaneously to avoid the mixing of erroneous data caused by a single device failure (such as abnormal camera frame rate or sensor offset), thus eliminating "faulty data" from the source. This dual-device cross-verification mechanism constructs a "double insurance" for data quality, further improving data reliability.

[0113] In other embodiments, cross-verification of driving data from the first device and driving data from the second device includes:

[0114] A sliding window is used to cross-validate the original driving data of the first device and the original driving data of the second device. When the difference between the data within the same time window is greater than the threshold, the original driving data of the first device and the original driving data of the second device after a certain time interval are discarded.

[0115] In the above scheme, a sliding window mutual verification mechanism is used to verify the driving data of the two devices, which enhances the accuracy and reliability of the data from multiple dimensions: by defining a fixed time window (such as within 1 second), the raw data of the first device and the second device are compared in real time, which can accurately capture the consistency of data within the same time period and avoid misjudgment caused by time misalignment; when the data difference within the window exceeds the threshold, not only is the current data discarded, but the data of the second device after a certain time interval is also removed. This is because sensor failures or external interference are often persistent, and clearing related data can effectively cut off the abnormal data chain and prevent "contamination" of subsequent collection content; this mechanism effectively copes with sudden interference in complex scenarios.

[0116] For example, when a vehicle passes through a tunnel, the onboard camera may generate noisy data due to sudden changes in light, and the inertial measurement unit (IMU) may also experience short-term deviations due to electromagnetic interference. Sliding window cross-verification can quickly identify such anomalies and prevent invalid data from entering the storage stage through a collateral clearing strategy. At the same time, this method also supports dynamic adjustment of the time window size and difference threshold, and adaptive optimization based on vehicle driving status (such as shortening the window to improve sensitivity when driving at high speed) and environmental parameters (such as relaxing the threshold in rainy weather to avoid accidental deletion), thereby improving the accuracy of anomaly data removal. This provides a solid data foundation for subsequent accident analysis, driving behavior modeling, etc., and ensures high reliability throughout the data lifecycle.

[0117] Secondly, please refer to Figure 5 This application provides a vehicle data processing apparatus applicable to the vehicle data processing method as described in any of the above embodiments, comprising:

[0118] The data acquisition layer 1000 includes a mobile device 100, which collects and uploads data in real time.

[0119] The node layer 2000 includes supervisory nodes 200, consensus nodes 300, and user nodes 400. At least one of the supervisory nodes 200, consensus nodes 300, and user nodes 400 can upload to or access the consortium blockchain.

[0120] The second aspect of this application proposes a vehicle data processing device based on a consortium blockchain. Through a layered architecture and multi-node collaborative design, it brings significant advantages to the full lifecycle management of vehicle data: the mobile device in the data acquisition layer adopts multi-sensor fusion technology to collect key vehicle data in real time and complete preprocessing and mutual verification at the edge, ensuring the authenticity and accuracy of the data uploaded to the blockchain; the management node, with its high-privilege configuration, enables real-time auditing and compliance supervision of the entire data, effectively curbing the risk of data tampering; the consensus node performs distributed verification of data blocks based on an improved PBFT algorithm, and only after more than a preset number of nodes confirm the data is it marked as trustworthy, ensuring the immutability of data storage; the user node grants vehicle owners autonomous control over their data, allowing them to flexibly authorize the scope of data access, avoiding privacy leaks and helping to improve data reliability.

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

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

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

[0124] Although embodiments of this application have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of this application, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A method for processing vehicle data based on a consortium blockchain, characterized in that, Includes the following steps: In response to a user node's reporting instruction, the timestamp information of the reporting instruction is obtained, and a first encrypted message with a timestamp is generated based on the vehicle's key data; A node acquires multiple pieces of the first encrypted information, and according to the permissions assigned based on the node type, classifies and packages the multiple pieces of the first encrypted information into blocks by time nodes and stores them. When an extraction instruction is received from a certain node, the time information in the extraction instruction is extracted, and the corresponding storage block is extracted based on the time information.

2. The driving data processing method according to claim 1, characterized in that, The generation of the first encrypted information based on key vehicle data includes: Collect raw data from multiple devices and perform cross-verification; When the data difference within the same time window is less than the dynamic threshold, the data is retained and a feature tree is generated. The dynamic threshold is calculated based on real-time environmental parameters. Based on the timestamp information, multi-level hash values ​​are generated step by step in the feature tree. The multi-level hash values ​​include the original data hash, cross-device fusion hash and timestamp hash, which are combined to form the first encrypted information.

3. The driving data processing method according to claim 2, characterized in that, After the node obtains multiple pieces of the first encrypted information, it performs the following steps: The signature validity of the header hash value is verified by extracting the header hash value from multiple first encrypted messages using the public key of the supervisory node.

4. The driving data processing method according to claim 3, characterized in that, After verifying the signature validity of the header hash value, the following steps are performed: Once more than a preset number of nodes have verified the signature as valid, the corresponding storage block is marked as a trusted storage unit, and an accident reconstruction model is generated based on the original data. The accident reconstruction model is then bound to the hash value of the original data for storage.

5. The driving data processing method according to claim 4, characterized in that, After verifying the signature validity of the header hash value, the following steps are performed: A hash tree is generated based on the verified trusted data units and their corresponding timestamp information. A unique block containing the vehicle identifier and consensus node signature is then generated based on the hash tree.

6. The driving data processing method according to claim 1, characterized in that, After extracting the corresponding storage block based on the time information, the following steps are performed: Determine the permission type of the node that issued the extraction command, and verify the access legitimacy according to the preset permission rules.

7. The driving data processing method according to claim 6, characterized in that, The step of verifying access legitimacy according to preset permission rules includes: Determine whether the node issuing the extraction command has a supervisory node permission type. If so, increase the initial permission level of the extraction command; otherwise, decrease the initial permission level of the extraction command.

8. The driving data processing method according to claim 6, characterized in that, The generation of the first encrypted information with a timestamp based on key vehicle data includes: The system acquires driving data from multiple devices, including a first device and a second device. It collects driving data from the first device and the second device, and performs cross-verification between the driving data from the first device and the second device. If the cross-verification is true, it proceeds to the next step; otherwise, it discards both the driving data from the first device and the driving data from the second device.

9. The driving data processing method according to claim 8, characterized in that, The step of cross-verifying the driving data of the first device and the driving data of the second device includes: The original driving data of the first device and the original driving data of the second device are cross-validated using a sliding window. When the data difference within the same time window is greater than a threshold, the original driving data of the first device and the original driving data of the second device after a certain time interval are discarded.

10. A vehicle data processing device based on a consortium blockchain, applicable to the vehicle data processing method as described in any one of claims 1 to 9, characterized in that, include: The data acquisition layer includes a mobile device that collects and uploads data in real time. The node layer includes supervisory nodes, consensus nodes, and user nodes, at least one of which can upload to or access the consortium blockchain.

Images