Vehicle data provenance system, method, and electronic device

Abstract

The application provides a vehicle data tracing system, method and electronic equipment, wherein the system comprises: a data acquisition layer configured to acquire multi-source data of a vehicle under various working conditions; a data transmission record layer configured to generate first tracing metadata for each piece of original data in the received multi-source data, to characterize and record the whole life cycle of the original data; a consortium chain layer configured to store the first tracing metadata if it is judged that the received first tracing metadata meets storage conditions, the storage conditions including passing of legality verification and passing of consensus verification; and a data tracing layer configured to respond to an external data tracing request, to query target tracing metadata and to conduct trusted verification of the target tracing metadata in cooperation with the consortium chain layer, and to generate a tracing result. For vehicle data, a complete tracing chain from acquisition to transmission can be formed, and trusted notarization is combined with the consortium chain, so that the whole-cycle trusted traceability of vehicle data is realized.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a vehicle data traceability system, method and electronic device. Background Technology

[0002] As vehicle intelligence continues to improve, driving systems rely heavily on real-time measurement data from various sensors in areas such as environmental perception, behavioral decision-making, and path planning. This real-time measurement data also provides reliable support for continuous algorithm optimization. Therefore, building a reliable data traceability mechanism has become a core requirement. This mechanism not only accurately traces the source of data but also provides a verifiable chain of evidence for algorithm optimization and in the event of anomalies, thereby enhancing the credibility and security of the entire vehicle system.

[0003] In related technologies, vehicle data traceability generally adopts a centralized database architecture to manage and store traceability metadata, with all data writing, querying, and auditing relying on a central node. However, this approach still has certain drawbacks, including the risk of single points of failure and data tampering, and the difficulty in achieving complete data traceability. Consequently, it cannot achieve reliable traceability of vehicle data throughout its entire lifecycle, affecting the trustworthy application of vehicle data in high-security scenarios. Summary of the Invention

[0004] This application discloses a vehicle data traceability system, method, and electronic device to solve the technical problem of the inability to achieve reliable traceability of data throughout the entire lifecycle in vehicle data traceability.

[0005] In a first aspect, this application provides a vehicle data traceability system, the system comprising: a data acquisition layer for acquiring multi-source data of a vehicle under various operating conditions, the multi-source data including multiple raw data from different sensors; a data transmission recording layer for receiving the multi-source data from the data acquisition layer and generating first traceability metadata for each raw data in the multi-source data, the first traceability metadata being used to characterize and record the entire lifecycle of the raw data; a consortium blockchain layer for receiving the first traceability metadata from the data transmission recording layer, and storing the first traceability metadata if it is determined that the first traceability metadata meets preset storage conditions, wherein the storage conditions include passing legality verification and passing consensus verification; and a data traceability layer for responding to external data traceability requests, cooperating with the consortium blockchain layer to query target traceability metadata and perform trusted verification of the target traceability metadata, and generating traceability results based on the obtained target traceability metadata and trusted verification results.

[0006] In a first possible implementation of the first aspect, the data transmission recording layer includes: an identification module for generating a data identifier for each piece of original data in the multi-source data; an extraction and recording module for extracting data collection information and attribute information from the original data, and recording the flow information of the original data, wherein the collection information includes sensor identifier, collection time and collection location, the attribute information includes data type and data size, and the flow information includes sending and receiving nodes, sending and receiving timestamps, and transmission path within the data distribution service domain; a construction module for constructing the first traceability metadata based on the data identifier, the collection information, the attribute information, and the flow information; and an on-chain triggering module for sending the first traceability metadata to the consortium blockchain layer.

[0007] In the first possible implementation of the first aspect, a data transmission recording layer is constructed based on the data distribution service middleware. This layer includes an identification module, a data extraction and recording module, a construction module, and an on-chain triggering module. It can capture and record traceability-related information in real time and natively during data transmission, forming a complete traceability chain and clarifying the specific composition of traceability-related information. This achieves a deep integration of efficient data distribution capabilities and blockchain trusted evidence storage mechanism, ensuring both data transmission efficiency and the credibility of traceability information.

[0008] In a second possible implementation of the first aspect, the consortium blockchain layer includes vehicle-mounted nodes, cloud-based full nodes, and regulatory nodes deployed by consortium members. The consortium members include vehicle manufacturers, sensor suppliers, decision-making algorithm providers, traffic regulatory agencies, and testing institutions. The vehicle-mounted nodes are used to bind vehicle identifiers and verify the legality of the received first traceability metadata, and to package multiple pieces of first traceability metadata that have passed legality verification under the same vehicle identifier into blocks. The cloud-based full nodes are used to perform consensus verification on the blocks according to a preset consortium blockchain consensus mechanism, and to store the consensus-verified blocks in the node ledgers of each consortium member. The regulatory nodes, upon receiving a traceability query instruction from the data traceability layer, respond to the traceability query instruction by querying the target traceability metadata and verifying the credibility of the target traceability metadata.

[0009] In the second possible implementation of the first aspect, a consortium blockchain layer adapted to the vehicle environment is constructed to address the characteristics of high vehicle mobility and unstable in-vehicle networks. This layer integrates in-vehicle nodes, cloud-based full nodes, and regulatory nodes to form a hierarchical collaborative architecture. This not only improves the efficiency of data processing and traceability but also ensures the reliable operation of traceability services regardless of the vehicle's operating condition.

[0010] In a third possible implementation of the first aspect, the cloud-based full nodes are further used to construct a first-level index and a second-level index for each first traceability metadata in the consensus-verified block, wherein the first-level index includes a data identifier, and the second-level index includes a vehicle identifier, a sensor identifier, and a collection time range.

[0011] In the third possible implementation of the first aspect, all nodes in the cloud simultaneously build and maintain the first-level and second-level indexes of each first traceability metadata while storing blocks, which significantly improves the traceability efficiency under high data volume.

[0012] In the fourth possible implementation of the first aspect, the regulatory node is configured to query the target block where the target traceability metadata is located from all nodes in the cloud according to the query conditions in the traceability query instruction and the secondary index, and perform chain hash verification on the target block. The query conditions include the vehicle identifier, sensor identifier, collection time, and data identifier corresponding to the target traceability metadata. The node is also configured to query the target traceability metadata from the target block according to the query conditions and the primary index, perform Merkle tree verification on the target traceability metadata, and feed back the target traceability metadata and the obtained trusted verification result to the data traceability layer.

[0013] In the fourth possible implementation of the first aspect, the regulatory node achieves efficient querying of target traceability metadata by utilizing the first-level and second-level indexes pre-built by all nodes in the cloud. In the query process, chain hash verification and Merkle tree verification are introduced, which greatly improves the efficiency and credibility of data traceability.

[0014] In a fifth possible implementation of the first aspect, the data transmission recording layer further includes: an encapsulation and distribution module, configured to compress the original data, encapsulate it together with the first traceability metadata into a data packet, and send the data packet to an external decision-making system so that the external decision-making system can make a decision based on the data packet; and to send the data packet to the on-chain triggering module so that the on-chain triggering module can extract the first traceability metadata from the data packet and send it to the consortium blockchain layer.

[0015] In the fifth possible implementation of the first aspect, the data transmission record layer distributes the original data and uploads the first traceability metadata to the blockchain through the encapsulation and distribution module, ensuring the close coupling and efficient collaboration between the data distribution process and the traceability data upload process.

[0016] In a sixth possible implementation of the first aspect, the system further includes: a digital twin collaboration layer, configured to send a data retrieval request from an external digital twin system to the data tracing layer, so that the data tracing layer responds to the data retrieval request, obtains trusted data verified by the consortium blockchain layer, and feeds back the trusted data from the data tracing layer to the external digital twin system, so that the external digital twin system performs decision simulation based on the trusted data.

[0017] In the sixth possible implementation of the first aspect, by introducing a digital twin collaboration layer, the collaboration between data traceability and digital twin technology is strengthened, enabling the external digital twin system to obtain credibly verified vehicle data, thereby conducting decision simulation and significantly improving the reliability and confidence of the simulation results.

[0018] In a seventh possible implementation of the first aspect, the data transmission recording layer is further configured to receive decision simulation data from the external digital twin system, generate second traceability metadata for the decision simulation data, and send the second traceability metadata to the consortium blockchain layer, so that the consortium blockchain layer stores the second traceability metadata when it determines that the second traceability metadata meets the storage conditions, wherein the second traceability metadata includes simulation process information and simulation result information of the decision simulation data.

[0019] In the seventh possible implementation of the first aspect, a second traceability metadata containing simulation process information and simulation result information is generated for the decision simulation data through a data transmission recording layer, and the second traceability metadata is stored through a consortium blockchain layer. On the basis of providing credible data for digital twins, the decision simulation data is also incorporated into the traceability system, realizing a closed loop from real-world data collection to digital twin simulation verification, and then to the on-chain storage of simulation results. This supports the traceability of the entire decision simulation process and significantly improves the credibility and interpretability of digital twins in vehicle decision verification.

[0020] Secondly, this application also provides a vehicle data traceability method, the method comprising: collecting multi-source data of a vehicle under various operating conditions, the multi-source data including multiple raw data from different sensors; generating first traceability metadata for each raw data in the multi-source data, the first traceability metadata being used to characterize and record the entire lifecycle of the raw data; storing the first traceability metadata if it is determined that the first traceability metadata meets preset storage conditions, wherein the storage conditions include passing legality verification and passing consensus verification; responding to an external data traceability request, querying target traceability metadata and performing trusted verification of the target traceability metadata, and generating a traceability result based on the obtained target traceability metadata and trusted verification result.

[0021] Thirdly, this application also provides an electronic device, including: a processor; and a storage device for storing a program, which, when executed by the processor, causes the electronic device to implement the vehicle data tracing method described above.

[0022] The beneficial effects of this application are as follows: This application provides a vehicle data traceability system, method, and electronic device, which integrates a data acquisition layer, a data transmission recording layer, a consortium blockchain layer, and a data traceability layer. The data acquisition layer is used to collect multi-source data from the vehicle under various operating conditions, including multiple raw data streams from different sensors. The data transmission recording layer is used to receive the multi-source data from the data acquisition layer and generate first traceability metadata for each raw data stream, used to characterize and record the entire lifecycle of the raw data. The consortium blockchain layer is used to receive the first traceability metadata from the data transmission recording layer, and if it is determined that the first traceability metadata meets preset storage conditions, it stores the first traceability metadata. The storage conditions include legality verification. The authentication and consensus verification are passed; the data traceability layer is used to respond to external data traceability requests, coordinate with the consortium blockchain layer to query and reliably verify the target traceability metadata, and generate traceability results based on the obtained target traceability metadata and the reliably verified results. Through a layered architecture design, the data acquisition layer realizes multi-source data acquisition, the data transmission and recording layer generates traceability metadata for the entire lifecycle, the consortium blockchain layer performs secure storage, and the data traceability layer provides query and reliably verified results. It can capture and record traceability-related information of data in real time and natively during data transmission, forming a complete traceability chain from collection to transmission. Combined with the anti-tampering capabilities of the consortium blockchain, the information of the entire process is reliably stored, realizing full-lifecycle reliable traceability of vehicle data. Attached Figure Description

[0023] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0024] In the attached diagram: Figure 1 This is a schematic diagram illustrating an optional vehicle data traceability system implementation environment, as shown in an exemplary embodiment of this application. Figure 2 This is a block diagram illustrating an optional vehicle data tracing system as an exemplary embodiment of this application; Figure 3 This is a block diagram illustrating an optional data transmission recording layer in an exemplary embodiment of this application; Figure 4 This is a block diagram illustrating an optional consortium blockchain layer, as shown in an exemplary embodiment of this application. Figure 5 This is a block diagram illustrating an optional specific vehicle data tracing system as an exemplary embodiment of this application; Figure 6 This is a schematic diagram illustrating the interaction process between an optional vehicle data traceability system and an external digital twin system, as shown in an exemplary embodiment of this application. Figure 7 This is a schematic flowchart illustrating an optional vehicle data tracing method as an exemplary embodiment of this application; Figure 8 This is a schematic diagram illustrating the structure of an optional electronic device, as shown in an exemplary embodiment of this application. Detailed Implementation

[0025] The following specific examples illustrate the implementation of this application. Those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. This application can also be implemented or applied through other different specific embodiments. Various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this application. In the absence of conflict, the following embodiments and features in the embodiments can be combined with each other.

[0026] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of this application. The drawings only show the components related to this application and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the shape, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0027] In the following description, numerous details are explored to provide a more thorough explanation of embodiments of the present application. However, it will be apparent to those skilled in the art that embodiments of the present application may be practiced without these specific details. In other embodiments, well-known structures and devices are shown in block diagram form rather than in detail to avoid obscuring embodiments of the present application.

[0028] As vehicle intelligence levels continue to improve, driving systems rely heavily on real-time measurement data from various sensors in environmental perception, behavioral decision-making, and path planning. This real-time measurement data also provides reliable support for continuous algorithm optimization, especially in autonomous and intelligent connected vehicles. Therefore, building a reliable data traceability mechanism has become a core requirement, providing effective data support for intelligent transportation systems. Currently, vehicle data traceability typically employs a centralized database architecture to manage and store traceability metadata, with all data writing, querying, and auditing relying on a central node. However, this approach is prone to single points of failure and data tampering risks, and makes complete data traceability difficult, thus hindering the reliable full-lifecycle traceability of vehicle data and impacting its trustworthy application in high-security scenarios.

[0029] Therefore, please see Figure 1 , Figure 1 This is a schematic diagram illustrating an optional vehicle data traceability system implementation environment, as shown in an exemplary embodiment of this application. Figure 1 As shown, the implementation environment may include a vehicle data traceability system 110 and a computer device 120. The vehicle data traceability system 110 can be installed within the computer device 120 to realize vehicle data traceability. The vehicle data traceability system 110, through a layered architecture design, uses a data acquisition layer to acquire multi-source data, a data transmission and recording layer to generate traceability metadata for the entire lifecycle, a consortium blockchain layer for secure storage, and a data traceability layer to provide query and trusted verification. It can capture and record traceability-related information in real-time and natively during data transmission, forming a complete traceability chain from acquisition to transmission. Combined with the anti-tampering capabilities of the consortium blockchain, the entire process information is reliably stored, achieving full-lifecycle trusted traceability of vehicle data.

[0030] Please see Figure 2 , Figure 2 This is a block diagram illustrating an optional vehicle data tracing system as an exemplary embodiment of this application. This system can be applied to... Figure 1 The implementation environment shown is intended to illustrate the system, but it should be understood that the system can also be applied to other exemplary implementation environments. This embodiment does not limit the implementation environment to which the system is applicable.

[0031] like Figure 2As shown, in an exemplary embodiment, the vehicle data traceability system 200 includes at least a data acquisition layer 210, a data transmission recording layer 220, a consortium blockchain layer 230, and a data traceability layer 240, which are described in detail below: The data acquisition layer 210 is used to collect multi-source data of the vehicle under various operating conditions. The multi-source data includes multiple raw data from different sensors.

[0032] The sensors include cameras, millimeter-wave radar, lidar, IMU (Inertial Measurement Unit), GPS (Global Positioning System), and wheel speed sensors; the operating conditions include stationary and moving states; the multi-source data includes road environment data and vehicle state data; the road environment data is used to characterize the dynamic and static traffic elements around the vehicle, including road data (such as lane lines, road boundaries, curvature, slope, and road surface conditions), pedestrian data (such as position, speed, and direction of movement), other vehicle data (such as relative position, relative speed, and driving trajectory), and traffic sign data (such as speed limit signs, stop signs, and traffic light status); the vehicle state data includes vehicle speed data (such as longitudinal speed, lateral speed, and wheel speed), steering data (such as steering wheel angle, steering angular velocity, and front wheel angle), attitude data (such as pitch angle, roll angle, and yaw angle), and braking and drive data (brake pedal opening, gear status, and motor torque), etc.

[0033] In this embodiment, the data acquisition layer 210 is configured as the initial stage layer of the vehicle data traceability system. It consists of various sensors deployed on the vehicle, responsible for collecting all raw data of the vehicle under various operating conditions. Each sensor is assigned a unique Sensor ID (i.e., sensor identifier), which has been pre-registered and stored in the consortium blockchain layer to ensure the legitimacy and initial trustworthiness of the data source.

[0034] The data transmission recording layer 220 is used to receive multi-source data from the data acquisition layer 210 and generate first traceability metadata for each piece of original data in the multi-source data. The first traceability metadata is used to characterize and record the entire lifecycle of the original data.

[0035] Among them, the first traceability metadata refers to the data packet generated by the data transmission record layer 220 for each piece of original data, including the basic information and transmission information of the original data and other full lifecycle information.

[0036] In this embodiment, the data transmission recording layer 220 is configured as an intermediate layer between the data acquisition layer 210 and the consortium blockchain layer 230. Its main responsibility is to receive multi-source data from the data acquisition layer 210 and generate metadata for each piece of original data for traceability, so as to ensure the full life cycle traceability of vehicle data.

[0037] In one embodiment, please refer to Figure 3 , Figure 3 This is a block diagram illustrating an optional data transmission recording layer, as shown in an exemplary embodiment of this application. Figure 3 As shown, the data transmission recording layer 220 includes at least: an identification module 221, used to generate a data identifier for each piece of raw data in the multi-source data; an extraction and recording module 222, used to extract the data collection information and attribute information from the raw data, and record the flow information of the raw data, wherein the collection information includes sensor identifier, collection time and collection location, the attribute information includes data type and data size, and the flow information includes sending and receiving nodes, sending and receiving timestamps and the transmission path within the data distribution service domain; a construction module 223, used to construct the first traceability metadata based on the data identifier, collection information, attribute information and flow information; and an on-chain triggering module 224, used to send the first traceability metadata to the consortium blockchain layer 230.

[0038] Among them, Data ID (i.e., data identifier) ​​is a globally unique identifier for the raw data; Sensor ID refers to the identifier of the sensor that directly collects the raw data; Data types include image data, point cloud data, and text data.

[0039] In this embodiment, considering that vehicles generally use DDS (Data Distribution Service) middleware to achieve efficient real-time transmission of sensor data between modules, but it cannot record key traceability information such as data flow path and processing nodes, the data transmission recording layer 220 adopts an enhanced data communication architecture based on DDS. This architecture can not only receive, route and distribute massive amounts of sensor data, but also capture and record the complete lifecycle information of the data in real time and natively while receiving, routing and distributing the data.

[0040] In this embodiment, the identification module 221 assigns a unique data identifier to each piece of original data, ensuring the uniqueness and identifiability of the data in subsequent processing and tracing. The extraction and recording module 222 extracts the data collection and attribute information from the original data, and records the flow information of the original data, systematically collecting and organizing the key context information of the original data, providing detailed evidence for subsequent tracing. The sending and receiving nodes recorded by the extraction and recording module 222 can be represented by the unique identifiers of the devices or services involved in the data transmission process, such as the sensor driving module identifier at the sending end and the perception fusion module identifier at the receiving end. The recorded transmission path in the DDS domain refers to the sequence of DDS nodes that the original data passes through from the source to the destination, which can be represented by the unique identifier of each DDS node. The construction module 223 integrates the data identifier, collection information, attribute information, and flow information corresponding to the original data to form a structured metadata object, ensuring the parsability of the first traceability metadata. The on-chain triggering module 224 is responsible for interacting with the consortium blockchain layer 230 to submit the constructed first traceability metadata to the blockchain network.

[0041] In this embodiment, based on the DDS middleware, a data transmission recording layer 220 is constructed, which includes an identification module 221, a data extraction and recording module 222, a construction module 223, and an on-chain triggering module 224. Unlike the mode of transmitting data first and then supplementing traceability information, this layer can capture and record traceability-related information of data in real time and natively during the DDS data transmission process, forming a complete traceability chain and clarifying the specific composition of traceability-related information. It includes both the basic information of the data itself and the flow information during the data transmission process, and can clearly and meticulously record the entire process of data from generation to use. This achieves a deep integration of DDS's efficient data distribution capability and the blockchain's trusted evidence storage mechanism, ensuring both data transmission efficiency and the credibility of traceability information.

[0042] In addition, relying on DDS's efficient data distribution capabilities and the loosely coupled architecture of the consortium blockchain, the system can flexibly connect to new sensors and new decision-making algorithms, improving the system's scalability and compatibility.

[0043] In one possible embodiment, the data identifier can be generated by performing a hash operation on the original data and using the resulting hash value as the data identifier; or by fusing information such as the sensor identifier, collection time, and collection location corresponding to the original data to construct the data identifier.

[0044] In one possible embodiment, the on-chain triggering module 224 can digitally sign the first traceability metadata before sending it, so that the consortium blockchain layer 230 can verify the authenticity and integrity of the source of the first traceability metadata. Additionally, the sending mechanism can be set to real-time sending according to system requirements to ensure that the first traceability metadata can be recorded on the consortium blockchain in a timely and secure manner.

[0045] The consortium blockchain layer 230 is used to receive the first traceability metadata from the data transmission record layer 220, and to store the first traceability metadata if it is determined that the first traceability metadata meets the preset storage conditions, wherein the storage conditions include passing the legality verification and passing the consensus verification.

[0046] Among them, the legitimacy verification is to determine whether the first traceability metadata conforms to the standard; the consensus verification is to determine whether the first traceability metadata has been recognized by the alliance members.

[0047] In this embodiment, the consortium blockchain layer 230 is built on blockchain technology and is jointly maintained by multiple consortium members. After receiving the first traceability metadata, it will perform legality verification and consensus verification on the first traceability metadata. Only when both pass will the first traceability metadata be stored on the blockchain to ensure data quality and data trustworthiness, and to achieve the immutability of the first traceability metadata.

[0048] In one embodiment, please refer to Figure 4 , Figure 4 This is a block diagram illustrating an optional consortium blockchain layer, as shown in an exemplary embodiment of this application. Figure 4 As shown, the consortium blockchain layer 230 includes vehicle-mounted nodes 231, cloud-based full nodes 232, and regulatory nodes 233 deployed by consortium members. Consortium members include vehicle manufacturers, sensor suppliers, decision-making algorithm providers, traffic regulatory agencies, and testing agencies. Vehicle-mounted nodes 231 are used to bind vehicle identifiers and verify the legality of received first traceability metadata, and package multiple first traceability metadata records that have passed legality verification under the same vehicle identifier into blocks. Cloud-based full nodes 232 are used to perform consensus verification on blocks according to a preset consortium blockchain consensus mechanism, and store the blocks that have passed consensus verification into the node ledgers of each consortium member. Regulatory nodes 233 are used to respond to traceability query instructions from the data traceability layer by querying the target traceability metadata and verifying the credibility of the target traceability metadata.

[0049] Among them, decision algorithm providers refer to software developers such as path planning algorithms and behavior control algorithms; testing agencies refer to third-party certification or verification units.

[0050] In this embodiment, the consortium blockchain layer 230 introduces consortium members such as vehicle manufacturers, sensor suppliers, decision algorithm providers, traffic regulatory agencies, and testing agencies. Each consortium member can have one or more identities and jointly deploy vehicle nodes 231, cloud-based full nodes 232, and regulatory nodes 233. The nodes can be securely connected through encrypted communication protocols to achieve separation of responsibilities and collaborative work, forming a layered and collaborative consortium blockchain architecture.

[0051] In this embodiment, after receiving the first traceability metadata, the vehicle-mounted node 231 associates it with the vehicle's unique identifier. Simultaneously, it verifies the legitimacy of the first traceability metadata and packages multiple valid first traceability metadata entries under the same vehicle identifier into a block to be uploaded to the blockchain. This packaging operation can be dynamically triggered based on a time window, the cumulative number of data entries, or the cumulative data volume. The cloud-based full-scale node 232 receives the block from the vehicle-mounted node 231 and verifies the block through a pre-defined consortium blockchain consensus mechanism. This ensures that the block remains consistent and immutable even if some nodes fail or malicious behavior occurs. If the block passes consensus verification, it is added to the distributed ledger of all participating cloud-based full-scale nodes, achieving permanent block solidification. Supervisory node 233 provides data query and trusted verification services. If it receives a traceability query instruction from the data traceability layer 240, the node will respond to the instruction and send a query request to all nodes 232 in the cloud to retrieve target traceability metadata that meets the conditions. At the same time, supervisory node 233 will also perform trusted verification on the retrieved target traceability metadata to ensure that it has not been tampered with.

[0052] In this embodiment, considering the characteristics of high vehicle mobility and unstable in-vehicle networks, a consortium blockchain layer 230 adapted to the in-vehicle environment is constructed. It integrates in-vehicle nodes 231, cloud-based full nodes 232, and regulatory nodes 233 to form a layered collaborative architecture. This not only improves the efficiency of data processing and traceability, but also ensures the reliable operation of traceability services when the vehicle is in any operating condition.

[0053] In one possible embodiment, the vehicle-mounted node 231 is deployed by the vehicle manufacturer, the cloud-based full-scale node 232 is deployed by the vehicle manufacturer, sensor supplier, decision algorithm provider, traffic regulatory agency and testing agency, and the regulatory node 233 is deployed by the traffic regulatory agency and testing agency.

[0054] In one possible embodiment, the legitimacy verification includes verifying whether the sensor identifier in the first traceability metadata is within the consortium blockchain whitelist, verifying whether the timestamp corresponding to the first traceability metadata is reasonable, and verifying whether the data format of the first traceability metadata is compliant.

[0055] In one possible embodiment, the pre-defined consortium blockchain consensus mechanism can employ consensus algorithms such as PBFT (Practical Byzantine Fault Tolerance), RAFT (a consensus protocol for distributed systems), and PoA (Proof of Authority) to achieve efficient consensus.

[0056] In one possible implementation, the vehicle node 231 will discard the first traceability metadata that fails the legitimacy verification, and the cloud full node 232 will also discard the block that fails the consensus verification.

[0057] In one embodiment, the cloud-based full-scale nodes 232 are also used to construct a primary index and a secondary index for each first traceability metadata in the consensus-verified block, wherein the primary index includes a data identifier, and the secondary index includes a vehicle identifier, a sensor identifier, and a collection time range.

[0058] In this embodiment, considering the bottleneck of query efficiency caused by massive vehicle data, a primary index and a secondary index are constructed to reduce the traceability response delay caused by traversing the entire blockchain ledger, so as to achieve efficient query of traceability data.

[0059] In this embodiment, while storing blocks, the cloud-based full node 232 simultaneously builds and maintains a first-level index and a second-level index for each first traceability metadata. The first-level index provides the ability to quickly and accurately locate a single first traceability metadata, while the second-level index supports combined queries and range queries based on multiple dimensions such as vehicle, sensor, and time. This allows the supervisory node 233 to avoid traversing the entire blockchain ledger, significantly improving traceability efficiency under high data volumes.

[0060] In one embodiment, the supervisory node 233 is used to query the target block where the target traceability metadata is located from the full number of nodes 232 in the cloud according to the query conditions and secondary index in the traceability query instruction, and to perform chain hash verification on the target block. The query conditions include the vehicle identifier, sensor identifier, collection time and data identifier corresponding to the target traceability metadata. The supervisory node 233 is also used to query the target traceability metadata from the target block according to the query conditions and primary index, and to perform Merkle tree verification on the target traceability metadata. The supervisory node 233 then feeds back the target traceability metadata and the obtained trusted verification results to the data traceability layer 240.

[0061] The traceability query command carries query conditions, which the regulatory node 233 can obtain by parsing the traceability query command. When determining the target block based on the query conditions and secondary index in the traceability query command, the target block is determined based on the vehicle identifier, sensor identifier, and collection time in the query conditions, combined with the secondary index. When determining the target traceability metadata from the target block based on the query conditions and primary index, the target traceability metadata is determined based on the data identifier in the query conditions, combined with the primary index.

[0062] In this embodiment, each block header contains the hash value of the previous block, forming an immutable hash chain. After obtaining the target block, the supervisory node 233 performs chain hash verification on the target block, that is, compares the hash value of the previous block stored in the header of the target block with the actual hash value of the previous block. If the chain hash verification of the target block passes, it proves that the target block itself has not been tampered with, and the target traceability metadata can be further queried from the target block. A Merkle tree is a hash tree structure whose root hash value is stored in the block header, representing the integrity of all data within the block. After locating the target traceability metadata, the supervisory node 233 performs Merkle tree verification on it, that is, compares the hash value of the target traceability metadata with the Merkle root recorded in the header of the target block. If the Merkle tree verification of the target traceability metadata passes, it proves that it has not been tampered with within the target block and is trustworthy.

[0063] In this embodiment, the supervisory node 233 utilizes the first-level and second-level indexes pre-built by the full cloud node 232 to achieve efficient querying of target traceability metadata. During the query process, chain hash verification and Merkle tree verification are introduced, which greatly improves the efficiency and credibility of data traceability.

[0064] The data traceability layer 240 is used to respond to external data traceability requests, collaborate with the consortium blockchain layer 230 to query and verify the target traceability metadata, and generate traceability results based on the obtained target traceability metadata and the verification results.

[0065] Among them, external data tracing requests refer to data tracing requests initiated by users (such as car company engineers, accident investigators, and traffic police) based on query clients, which carry query conditions.

[0066] In this embodiment, the data traceability layer 240 is configured to respond to external data traceability requests from query clients and perform vehicle data traceability. Specifically, when an external data traceability request is received, the query conditions in the external data traceability request are parsed, and a traceability query instruction is generated based on the query conditions and sent to the consortium blockchain layer 230. This allows the supervisory node 233 in the consortium blockchain layer 230 to query the target traceability metadata from all nodes 232 in the cloud based on the query instruction, and to perform trusted verification on the target traceability metadata. Then, the obtained target traceability metadata and trusted verification results are fed back to the data traceability layer 240. The data traceability layer 240 generates traceability results based on the received target traceability metadata and trusted verification results, and feeds the traceability results back to the query client, presenting them to the user in a visual form.

[0067] In one possible embodiment, the data tracing layer 240 also provides an API (Application Programming Interface).

[0068] In one embodiment, please continue to see Figure 3 The data transmission recording layer 220 also includes: an encapsulation and distribution module 225, which is used to compress the original data, encapsulate it together with the first traceability metadata into a data packet, and send the data packet to an external decision system so that the external decision system can make a decision based on the data packet, and send the data packet to the on-chain trigger module 224 so that the on-chain trigger module 224 can extract the first traceability metadata from the data packet and send it to the consortium blockchain layer 230.

[0069] External decision-making systems refer to downstream systems that use raw data to make decisions, such as path planning systems and drive control systems.

[0070] In this embodiment, considering that raw data typically occupies a large amount of space, an encapsulation and distribution module 225 is designed in the data transmission recording layer 220 to compress the raw data and reduce its space usage in order to reduce transmission bandwidth, storage space consumption, and ensure transmission efficiency. Simultaneously, to enable the external decision-making system to accurately reconstruct the raw data, the first traceability metadata and the compressed raw data are encapsulated into a data packet, which is then sent to the external decision-making system for easy transmission and parsing. Furthermore, to ensure the consistency of the first traceability metadata, the first traceability metadata sent by the data transmission recording layer 220 to the consortium blockchain layer 230 is obtained by separating it from the data packet, thus achieving secure separate storage of the raw data and the corresponding first traceability metadata.

[0071] In this embodiment, the data transmission recording layer 220 distributes the original data and uploads the first traceability metadata to the blockchain through the encapsulation and distribution module 225, ensuring the close coupling and efficient collaboration between the data distribution process and the traceability data upload process.

[0072] In one possible embodiment, the encapsulation and distribution module 225 utilizes the quality of service policy provided by DDS to ensure that data is reliably and in real time distributed to external decision-making systems.

[0073] In one embodiment, please refer to Figure 5 , Figure 5 This is a block diagram illustrating an optional specific vehicle data tracing system as an exemplary embodiment of this application. For example... Figure 5 As shown, the vehicle data traceability system 200 also includes at least: a digital twin collaboration layer 250, which sends data call requests from an external digital twin system to the data traceability layer 240, so that the data traceability layer 240 responds to the data call request, obtains trusted data verified by the consortium blockchain layer 230, and feeds back the trusted data from the data traceability layer 240 to the external digital twin system, so that the external digital twin system can perform decision simulation based on the trusted data.

[0074] Among them, external digital twin systems refer to systems that reproduce decisions and simulate scenarios; trusted data refers to data that has been verified by the consortium blockchain layer 230 and used for decision simulation.

[0075] In this embodiment, considering that vehicle decision reproduction and scenario simulation often rely on digital twin models, and the effectiveness of these models depends on highly reliable data, the lack of highly reliable vehicle data, or the inability to effectively verify the source, integrity, and authenticity of the data, will affect the accuracy and authority of the simulation results and severely restrict the interpretability of the black-box decision-making process. Therefore, a digital twin collaboration layer 250 is designed to establish a bridge between the system and external digital twin systems, ensuring that the vehicle's digital twin can be developed based on reliable data.

[0076] In this embodiment, please refer to Figure 6 , Figure 6 This is a schematic diagram illustrating the interaction process between an optional vehicle data traceability system and an external digital twin system, as shown in an exemplary embodiment of this application. Figure 6As shown, after receiving a data request from an external digital twin system, the digital twin collaboration layer calls the API interface of the data traceability layer to send the data request to the data traceability layer. Upon receiving the data request, the data traceability layer interacts with the consortium blockchain layer. Specifically, based on the vehicle identifier and time range carried in the data request, it verifies, through regulatory nodes and all cloud nodes, whether all primary traceability metadata under that vehicle identifier within that time range has been tampered with. If the data traceability layer obtains a result indicating that all primary traceability metadata under that vehicle identifier within that time range has not been tampered with, it can obtain all the original data of the corresponding vehicle within that time range from the data transmission record layer. This original data is trusted data verified by the consortium blockchain layer. The data traceability layer can then feed this trusted data back to the external digital twin system through the digital twin collaboration layer, enabling the external digital twin system to perform authoritative and interpretable decision simulations based on the trusted data.

[0077] In addition, the logic for verifying whether the first traceability metadata has been tampered with is still to perform the chain hash verification and Merkle tree verification mentioned above, which will not be described in detail here.

[0078] In this embodiment, by introducing a digital twin collaboration layer 250, the collaboration between data traceability and digital twin technology is enhanced, enabling the external digital twin system to obtain credibly verified vehicle data for decision simulation, thereby significantly improving the reliability and confidence of the simulation results.

[0079] In one embodiment, the data transmission recording layer 220 is further configured to receive decision simulation data from an external digital twin system, generate second traceability metadata for the decision simulation data, and send the second traceability metadata to the consortium blockchain layer 230, so that the consortium blockchain layer 230 stores the second traceability metadata when it determines that the second traceability metadata meets the storage conditions. The second traceability metadata includes simulation process information and simulation result information of the decision simulation data.

[0080] The simulation process information includes, but is not limited to, simulation start time, simulation end time, data usage records, simulator version used, simulation environment parameters, and decision algorithm version, which are used to characterize how the simulation was conducted; the simulation result information includes, but is not limited to, decision reproduction results and decision confidence scores, which are used to characterize the decision effect.

[0081] In this embodiment, please continue to refer to Figure 6The data transmission recording layer can receive decision simulation data from an external digital twin system and generate second traceability metadata for the decision simulation data. The logic for generating the second traceability metadata is the same as that for generating the first traceability metadata, and will not be detailed here. After obtaining the second traceability metadata, the data transmission recording layer sends the second traceability metadata to the consortium blockchain layer. Upon receiving it, the consortium blockchain layer first binds the second traceability metadata with the corresponding vehicle identifier, and then stores the second traceability metadata if it is determined that the second traceability metadata meets the storage conditions. The logic for determining whether the second traceability metadata meets the storage conditions and storing the second traceability metadata is the same as the logic for determining whether the first traceability metadata meets the storage conditions and storing the first traceability metadata, and will not be detailed here. Finally, the storage result is fed back to the data transmission recording layer.

[0082] In this embodiment, the data transmission recording layer 220 generates second traceability metadata containing simulation process information and simulation result information for the decision simulation data, and stores the second traceability metadata through the consortium blockchain layer 230. On the basis of providing credible data for digital twins, the decision simulation data is also incorporated into the traceability system, realizing a closed loop from real-world data collection to digital twin simulation verification, and then to the on-chain storage of simulation results. This supports the traceability of the entire decision simulation process and significantly improves the credibility and interpretability of digital twins in vehicle decision verification.

[0083] The aforementioned vehicle data traceability system integrates a data acquisition layer, a data transmission recording layer, a consortium blockchain layer, and a data traceability layer. The data acquisition layer collects multi-source data from the vehicle under various operating conditions, including multiple raw data points from different sensors. The data transmission recording layer receives the multi-source data from the data acquisition layer and generates first traceability metadata for each raw data point, representing and recording the entire lifecycle of the raw data. The consortium blockchain layer receives the first traceability metadata from the data transmission recording layer and, if it determines that the first traceability metadata meets preset storage conditions, stores the first traceability metadata. These storage conditions include successful legality verification and successful consensus verification. According to the traceability layer, it is used to respond to external data traceability requests, coordinate with the consortium blockchain layer to query and verify the target traceability metadata, and generate traceability results based on the obtained target traceability metadata and the trusted verification results. Through a layered architecture design, the data acquisition layer realizes multi-source data acquisition, the data transmission and recording layer generates traceability metadata for the entire lifecycle, the consortium blockchain layer performs secure storage, and the data traceability layer provides query and trusted verification. It can capture and record traceability-related information of data in real time and natively during data transmission, forming a complete traceability chain from collection to transmission. Combined with the anti-tampering capabilities of the consortium blockchain, the information of the entire process is trusted and evidenced, realizing full-lifecycle trusted traceability of vehicle data.

[0084] To illustrate this, let's take the scenario of determining liability after an accident involving an autonomous vehicle (hereinafter referred to as Vehicle A) at an intersection as an example. Vehicle A passes through the intersection when the traffic light is green and collides with an electric bicycle (hereinafter referred to as Vehicle B) that runs a red light. However, both parties have different opinions on the cause of the accident. Vehicle B believes that Vehicle A failed to avoid the collision in time, while Vehicle A insists that the autonomous driving decision was correct. In order to determine liability fairly, it is necessary to conduct a reliable tracing of the data on which Vehicle A's decision was based.

[0085] First, as vehicle A approaches the intersection, its lidar and camera continuously collect environmental data from the intersection, recording 10 environmental data points throughout the entire process of vehicle B running a red light and colliding with it. At this point, the data acquisition layer obtains this environmental data and sends it to the data transmission and recording layer.

[0086] Next, after receiving these 10 environmental data, the data transmission recording layer will generate corresponding traceability metadata for these intersection environmental data, characterize and record the entire lifecycle of these environmental data, and encapsulate these environmental data and corresponding traceability metadata, and send the data packet to the external decision-making system so that the external decision-making system can make decisions based on the received data packet, and extract the traceability metadata in the data packet and send it to the consortium blockchain layer.

[0087] Then, after receiving the 10 traceability metadata, the consortium blockchain layer will verify the legality of these metadata. If the legality verification is successful, the 10 traceability metadata will be packaged into a block, and the block will be verified by PBFT consensus by consortium members such as vehicle manufacturers, sensor suppliers, decision algorithm providers, traffic regulatory agencies, and testing agencies. If the consensus verification is successful, it will be permanently fixed on the chain. This ensures that the source information and flow information of all key data from before the accident to when the accident occurred have been recorded immutably.

[0088] Finally, during the accident investigation phase, traffic police can send a data tracing request to the data tracing layer via a query client. This request includes vehicle identification, sensor identification, collection time, and data identification. The data tracing layer generates a tracing query command based on the request and sends it to the consortium blockchain layer for verification of the authenticity of these 10 environmental data points. Specifically, the regulatory nodes in the consortium blockchain layer quickly locate the corresponding block using the index and extract these 10 sets of tracing metadata for chain hash verification and Merkle root verification. The verification results clearly show that all tracing metadata has never been tampered with since the accident occurred. In other words, these 10 environmental data points were indeed collected by LiDAR and cameras during the time of the accident and at the accident site.

[0089] In addition, to verify whether the decisions made by vehicle A during the accident were correct, a third-party testing agency can input the 10 trusted environmental data points, verified by the consortium blockchain layer, into the external digital twin system corresponding to vehicle A. The external digital twin system recreates the accident scenario: vehicle A approaches an intersection at a certain speed (e.g., 40 km / h), and vehicle B runs a red light from a side road at another speed (e.g., 25 km / h). In the decision simulation of the external digital twin system, the same decision-making algorithm as vehicle A is used. The simulation results show that the autonomous driving system identifies the risk within a certain time (e.g., 40 ms), but based on the relative distance at the time (e.g., 15 meters) and the vehicle's braking performance (e.g., requiring 20 meters), it determines that it cannot safely avoid the obstacle, consistent with the result in a real accident. Simultaneously, the external digital twin system can send the obtained decision simulation data to the data transmission and recording layer for on-chain storage of the decision simulation data.

[0090] In the aforementioned determination of liability, the vehicle data traceability system, which utilizes deeply integrated data distribution services and blockchain technology, combined with digital twin technology, has achieved reliable traceability of vehicle data throughout its entire lifecycle during the accident, forming an irrefutable chain of evidence and, to a certain extent, solving the problem of determining liability in intelligent driving.

[0091] Please see Figure 7 , Figure 7This is a schematic flowchart illustrating an optional vehicle data tracing method as shown in an exemplary embodiment of this application. This method can be applied to... Figure 1 The implementation environment shown is specifically executed by the vehicle data traceability system 110 within that implementation environment. It should be understood that this method can also be applied to other exemplary implementation environments and executed by devices in other implementation environments; this embodiment does not limit the implementation environment to which the method is applicable.

[0092] like Figure 7 As shown, in an exemplary embodiment, the vehicle data tracing method includes at least steps S710 to S740, which are described in detail below: Step S710: Collect multi-source data of the vehicle under various operating conditions. The multi-source data includes multiple raw data from different sensors. Step S720: Generate first source metadata for each piece of original data in the multi-source data. The first source metadata is used to characterize and record the entire lifecycle of the original data. Step S730: If it is determined that the first traceability metadata meets the preset storage conditions, then the first traceability metadata is stored, wherein the storage conditions include passing the legality verification and passing the consensus verification. Step S740: In response to an external data tracing request, query the target tracing metadata and perform a trusted verification of the target tracing metadata, and generate a tracing result based on the obtained target tracing metadata and the trusted verification result.

[0093] It should be noted that the vehicle data traceability method provided in the above embodiments and the vehicle data traceability system provided in the above embodiments belong to the same concept, and the content of each step has been described in detail in the system embodiments, and will not be repeated here.

[0094] Please see Figure 8 , Figure 8 This is a schematic diagram illustrating the structure of an optional electronic device, as shown in an exemplary embodiment of this application. Figure 8 A schematic diagram of a computer system suitable for implementing the embodiments of this application is shown. It should be noted that... Figure 8 The computer system 800 of the electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0095] like Figure 8As shown, the computer system 800 includes a Central Processing Unit (CPU) 801, which can perform various appropriate actions and processes, such as executing the methods described in the above embodiments, based on programs stored in Read-Only Memory (ROM) 802 or programs loaded from storage portion 808 into Random Access Memory (RAM) 803. The RAM 803 also stores various programs and data required for system operation. The CPU 801, ROM 802, and RAM 803 are interconnected via a bus 804. An Input / Output (I / O) interface 805 is also connected to the bus 804.

[0096] The following components are connected to I / O interface 805: an input section 806 including a keyboard, mouse, etc.; an output section 807 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 808 including a hard disk, etc.; and a communication section 809 including a network interface card such as a LAN (Local Area Network) card, modem, etc. The communication section 809 performs communication processing via a network such as the Internet. A drive 810 is also connected to I / O interface 805 as needed. A removable medium 811, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on drive 810 as needed so that computer programs read from it can be installed into storage section 808 as needed.

[0097] Specifically, according to embodiments of this application, the processes described in the above-referenced flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program including a computer program for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 809, and / or installed from removable medium 811. When the computer program is executed by central processing unit (CPU) 801, it performs various functions defined in the system of this application.

[0098] The above embodiments are merely illustrative of the principles and effects of this application and are not intended to limit this application. Any person skilled in the art can modify or alter the above embodiments without departing from the spirit and scope of this application. Therefore, all equivalent modifications or alterations made by those skilled in the art without departing from the spirit and technical concept disclosed in this application should still be covered by the claims of this application.

Claims

1. A vehicle data traceability system, characterized in that, The system includes: The data acquisition layer is used to collect multi-source data of the vehicle under various operating conditions. The multi-source data includes multiple raw data from different sensors. A data transmission recording layer is used to receive the multi-source data from the data acquisition layer and generate first traceability metadata for each piece of original data in the multi-source data. The first traceability metadata is used to characterize and record the entire lifecycle of the original data. The consortium blockchain layer is used to receive the first traceability metadata from the data transmission record layer, and to store the first traceability metadata if it is determined that the first traceability metadata meets the preset storage conditions, wherein the storage conditions include passing the legality verification and passing the consensus verification. The data tracing layer is used to respond to external data tracing requests, coordinate with the consortium blockchain layer to query the target tracing metadata and verify the credibility of the target tracing metadata, and generate tracing results based on the obtained target tracing metadata and the credibility verification results.

2. The vehicle data traceability system according to claim 1, characterized in that, The data transmission recording layer includes: The identification module is used to generate a data identifier for each piece of original data in the multi-source data; The extraction and recording module is used to extract the data acquisition information and attribute information from the raw data, and to record the flow information of the raw data. The acquisition information includes sensor identification, acquisition time and acquisition location, the attribute information includes data type and data size, and the flow information includes sending and receiving nodes, sending and receiving timestamps and transmission path within the data distribution service domain. The construction module is used to construct the first traceability metadata based on the data identifier, the collection information, the attribute information, and the flow information; The on-chain triggering module is used to send the first traceability metadata to the consortium blockchain layer.

3. The vehicle data traceability system according to claim 1, characterized in that, The consortium blockchain layer includes vehicle-mounted nodes, cloud-based full-scale nodes, and regulatory nodes deployed by consortium members, including vehicle manufacturers, sensor suppliers, decision-making algorithm providers, traffic regulatory agencies, and testing agencies. The vehicle-mounted node is used to bind vehicle identifiers and verify the legality of the received first traceability metadata, and to package multiple pieces of the first traceability metadata that have passed the legality verification under the same vehicle identifier into a block; The cloud-based full nodes are used to perform consensus verification on the blocks according to the preset consortium blockchain consensus mechanism, and store the blocks that pass the consensus verification into the node ledgers of each consortium member. The monitoring node is configured to, upon receiving a traceability query instruction from the data traceability layer, respond to the traceability query instruction by querying the target traceability metadata and verifying the credibility of the target traceability metadata.

4. The vehicle data traceability system according to claim 3, characterized in that, The cloud-based full nodes are also used to construct a first-level index and a second-level index for each of the first traceability metadata entries in the consensus-verified block, wherein the first-level index includes a data identifier, and the second-level index includes a vehicle identifier, a sensor identifier, and a collection time range.

5. The vehicle data traceability system according to claim 4, characterized in that, The monitoring node is used to query the target block where the target traceability metadata is located from all nodes in the cloud according to the query conditions in the traceability query instruction and the secondary index, and to perform chain hash verification on the target block. The query conditions include the vehicle identifier, sensor identifier, collection time and data identifier corresponding to the target traceability metadata. Based on the query conditions and the first-level index, the target traceability metadata is obtained from the target block, and Merkle tree verification is performed on the target traceability metadata. The target traceability metadata and the obtained trusted verification result are then fed back to the data traceability layer.

6. The vehicle data traceability system according to claim 2, characterized in that, The data transmission recording layer further includes: The encapsulation and distribution module is used to compress the original data, encapsulate it together with the first traceability metadata into a data packet, and send the data packet to an external decision-making system so that the external decision-making system can make a decision based on the data packet. The module also sends the data packet to the on-chain triggering module so that the on-chain triggering module can extract the first traceability metadata from the data packet and send it to the consortium blockchain layer.

7. The vehicle data traceability system according to any one of claims 1 to 6, characterized in that, The system also includes: The digital twin collaboration layer is used to send data call requests from external digital twin systems to the data tracing layer, so that the data tracing layer responds to the data call request, obtains trusted data verified by the consortium blockchain layer, and feeds back the trusted data from the data tracing layer to the external digital twin system, so that the external digital twin system can perform decision simulation based on the trusted data.

8. The vehicle data traceability system according to claim 7, characterized in that, The data transmission recording layer is further configured to receive decision simulation data from the external digital twin system, generate second traceability metadata for the decision simulation data, and send the second traceability metadata to the consortium blockchain layer, so that the consortium blockchain layer stores the second traceability metadata when it determines that the second traceability metadata meets the storage conditions, wherein the second traceability metadata includes simulation process information and simulation result information of the decision simulation data.

9. A method for tracing vehicle data, characterized in that, The method includes: Collect multi-source data of the vehicle under various operating conditions, including multiple raw data from different sensors; Generate first source traceability metadata for each piece of original data in the multi-source data, the first source traceability metadata being used to characterize and record the entire lifecycle of the original data; If it is determined that the first traceability metadata meets the preset storage conditions, then the first traceability metadata is stored, wherein the storage conditions include passing the legality verification and passing the consensus verification. In response to an external data tracing request, the system queries the target tracing metadata and performs a trusted verification of the target tracing metadata, and generates a tracing result based on the obtained target tracing metadata and the trusted verification result.

10. An electronic device, characterized in that, include: processor; A storage device for storing a program that, when executed by the processor, causes the electronic device to implement the steps of the vehicle data tracing method as described in claim 9.

Images