Multi-party collaborative automatic driving traffic responsibility determination method and system

Abstract

The embodiment of the application discloses a kind of multi-party collaborative automatic driving traffic responsibility determination method and system, wherein the method comprises: real-time acquisition of the original data of each data source;Each original data is calculated by hash digest;After the accident, the relevant original data of the data source involved in the accident within the accident time period is obtained, the actual hash digest is calculated and compared with the hash digest for integrity check;Identity verification is carried out according to identity certificate;According to the ciphertext accident characteristics of the relevant original data, a space-time consistency graph is constructed, the deviation data of each data source and the abnormal data source mark are calculated;According to the equipment state data, the identity verification result, the integrity check result and the deviation data, the trusted weight of the corresponding data source is calculated;According to the ciphertext accident characteristics and the trusted weight, the responsibility proportion of each responsible party is obtained;According to the responsibility proportion, the trusted weight, the space-time consistency graph and the abnormal data source mark, a responsibility determination report is generated and is chained to store evidence. The responsibility determination efficiency and the reliability are improved.

Description

Technical Field

[0001] This invention relates to the field of intelligent transportation, and in particular to a method and system for determining traffic liability in multi-party collaborative autonomous driving. Background Technology

[0002] With the rapid development of autonomous driving technology, autonomous vehicles are gradually moving from road testing to large-scale application, and the issue of determining liability in traffic accidents is becoming increasingly prominent. Currently, the determination of liability in autonomous driving traffic accidents mainly relies on manual communication with multiple parties, including car manufacturers, testing agencies, and insurance companies. This process is cumbersome, costly, and inefficient. Furthermore, vehicle operating data is typically stored and transmitted in a centralized manner, making it susceptible to tampering or falsification during collection, transmission, and storage, resulting in a lack of reliability and credibility in liability determination.

[0003] Regarding data sharing, directly sharing data from multiple parties in plaintext can easily lead to the leakage of sensitive information such as vehicle trajectory, driving behavior, and user identity, making it difficult to achieve fair, reliable, and traceable liability determination while protecting data privacy. Furthermore, existing technologies rely excessively on single-vehicle data for liability determination; when single-vehicle sensors malfunction, data is missing, or tampered with, the accuracy of liability determination cannot be guaranteed. For traffic accidents involving multiple vehicles, the lack of cross-verification mechanisms between vehicles makes it difficult to eliminate biases from a single data source. At the same time, existing solutions do not fully utilize global information such as road environment and traffic signals collected by roadside infrastructure (e.g., roadside units), resulting in significant limitations in liability determination results in complex traffic scenarios.

[0004] There is currently no effective solution to the above problems in existing technologies. Summary of the Invention

[0005] To address the aforementioned issues, this invention provides a method and system for determining traffic liability in multi-party collaborative autonomous driving. It ensures data immutability by hashing and storing multi-source data on the blockchain, performs multi-source cross-validation based on a spatiotemporal consistency graph to identify abnormal data sources and dynamically calculates trusted weights, and then calculates the liability ratio of each party within a secure multi-party computation framework by combining encrypted accident characteristics and preset liability rules. Finally, it generates a liability determination report and uploads it to the blockchain, thereby achieving efficient, reliable, and accurate automated liability determination while protecting data privacy.

[0006] To achieve the above objectives, this invention provides a method for determining traffic liability in multi-party collaborative autonomous driving, comprising: real-time collection of raw data from various data sources; wherein the raw data corresponding to the vehicle data source is vehicle operation data, and the raw data corresponding to the roadside unit data source is roadside environmental data; performing hash digest calculations on the raw data from each data source to obtain corresponding comparison hash digests and storing them on the blockchain; when a traffic accident occurs, acquiring the relevant raw data from each involved data source within the accident time period, calculating the actual hash digest of each relevant raw data, performing integrity verification based on the actual hash digest and the corresponding comparison hash digest, and obtaining the integrity verification result; and based on each involved data source... The identity credentials are used for identity verification to obtain the identity verification result; encrypted incident characteristics are obtained based on the relevant original data of each involved data source; a spatiotemporal consistency graph is constructed based on all encrypted incident characteristics; deviation data and abnormal data source markers are calculated based on the spatiotemporal consistency graph; the trust weight of each involved data source is calculated based on the device status data, the identity verification result, the integrity verification result, and the deviation data; each responsible party and its responsibility ratio are obtained based on the encrypted incident characteristics, trust weights, and the preset responsibility judgment model of each involved data source; a responsibility determination report is generated and stored on the blockchain based on the responsibility ratio, trust weights, spatiotemporal consistency graph, and abnormal data source markers.

[0007] Optionally, a spatiotemporal consistency map is constructed based on all encrypted incident features, including: extracting the timestamps and their corresponding spatial coordinates from each encrypted incident feature; using the timestamps as a time reference and the spatial coordinates as a spatial reference to construct a unified spatiotemporal coordinate system; adding involved vehicle nodes, roadside unit nodes, traffic signal nodes, road environment nodes, and incident nodes according to each encrypted incident feature in the unified spatiotemporal coordinate system; constructing vehicle trajectory edges, relative position edges, observation coverage edges, traffic light constraint edges, road environment influence edges, and collision association edges between nodes in the unified spatiotemporal coordinate system to obtain the spatiotemporal consistency map; wherein, the vehicle trajectory edge is the edge between involved vehicle nodes corresponding to the same vehicle at different timestamps, the relative position edge is the edge between involved vehicle nodes corresponding to different vehicles, the observation coverage edge is the edge between roadside unit nodes and related involved vehicles, the traffic light constraint edge is the edge between traffic signal nodes and related involved vehicles, the road environment influence edge is the edge between road environment nodes and related involved vehicle nodes, and the collision association edge is the edge between incident nodes and related involved vehicles.

[0008] Further optionally, the step of calculating the deviation data and abnormal data source markers between each involved data source based on the spatiotemporal consistency map includes: for each involved data source, comparing the motion trajectory of the involved data source with the corresponding motion trajectories of other involved data sources to obtain deviation data; comparing the deviation data of each involved vehicle with a preset deviation threshold, and marking the involved data source as an abnormal data source when the deviation data exceeds the preset deviation threshold.

[0009] Optionally, the step of calculating the trust weight of each data source involved in the incident based on the device status data, the identity verification result, the integrity verification result, and the deviation data includes: determining the device trust coefficient of each data source involved in the incident based on the device status data; determining the identity trust coefficient of each data source involved in the incident based on the identity verification result; determining the data integrity coefficient of each data source involved in the incident based on the integrity verification result; calculating the consistency coefficient of each data source involved in the incident based on the deviation data; and calculating the trust weight of the same data source involved in the incident based on the device trust coefficient, identity trust coefficient, data integrity coefficient, and consistency coefficient.

[0010] Optionally, the step of obtaining each responsible party and their respective responsibility ratio based on the encrypted incident characteristics, trust weights, and a preset accountability model of each involved data source includes: combining the encrypted incident characteristics and corresponding trust weights of each involved data source into input feature pairs; arranging the input feature pairs of all involved data sources in a preset order to construct a model input vector; and inputting the model input vector into the preset accountability model to obtain each responsible party and their respective responsibility ratio.

[0011] On the other hand, the present invention also provides a multi-party collaborative autonomous driving traffic liability determination system, comprising: a data acquisition module for real-time acquisition of raw data from various data sources; wherein the raw data corresponding to the vehicle data source is vehicle operation data, and the raw data corresponding to the roadside unit data source is roadside environmental data; a digest storage module for performing hash digest calculations on the raw data from each data source respectively, obtaining corresponding comparison hash digests and storing them on the blockchain; a first verification module for, when a traffic accident occurs, acquiring relevant raw data from each involved data source within the accident time period, calculating the actual hash digest of each relevant raw data respectively, performing integrity verification based on the actual hash digest and the corresponding comparison hash digest, and obtaining the integrity verification result; and a second verification module for, based on the data from each involved data source... The system includes: an identity verification module for identity authentication; a graph construction module for obtaining encrypted incident features based on relevant raw data from each involved data source, constructing a spatiotemporal consistency graph based on all encrypted incident features, and calculating deviation data and abnormal data source markers between each involved data source based on the spatiotemporal consistency graph; a weight calculation module for calculating the trust weight of each involved data source based on device status data, the identity verification result, the integrity verification result, and the deviation data; a responsibility allocation module for obtaining the responsibility of each party and the responsibility ratio of each party based on the encrypted incident features, trust weights, and a preset responsibility assessment model of each involved data source; and a report generation module for generating a responsibility assessment report based on the responsibility ratio, trust weights, spatiotemporal consistency graph, and abnormal data source markers, and storing the report on the blockchain.

[0012] Further optionally, the atlas construction module includes: a spatiotemporal coordinate system construction submodule, used to extract the timestamps and their corresponding spatial coordinates from each encrypted accident feature, and construct a unified spatiotemporal coordinate system using the timestamps as a time reference and the spatial coordinates as a spatial reference; a node adding submodule, used to add involved vehicle nodes, roadside unit nodes, traffic signal nodes, road environment nodes, and accident nodes in the unified spatiotemporal coordinate system according to each encrypted accident feature; and a node edge adding submodule, used to construct vehicle trajectory edges, relative position edges, and observation edges between nodes in the unified spatiotemporal coordinate system. The spatiotemporal consistency map is obtained by considering coverage edges, traffic light constraint edges, road environment influence edges, and collision association edges. Among them, the vehicle trajectory edge is the edge between the involved vehicle nodes corresponding to the same vehicle at different timestamps, the relative position edge is the edge between the involved vehicle nodes corresponding to different vehicles, the observation coverage edge is the edge between the roadside unit node and the relevant involved vehicle, the traffic light constraint edge is the edge between the traffic signal node and the relevant involved vehicle, the road environment influence edge is the edge between the road environment node and the relevant involved vehicle node, and the collision association edge is the edge between the accident node and the relevant involved vehicle.

[0013] Further optionally, the map construction module also includes: a deviation calculation submodule, used to compare the motion trajectory of each involved data source with the corresponding motion trajectory of other involved data sources to obtain deviation data; and an abnormal data source marking submodule, used to compare the deviation data of each involved vehicle with a preset deviation threshold, and when the deviation data exceeds the preset deviation threshold, mark the involved data source as an abnormal data source.

[0014] Further optionally, the weight calculation module includes: a first coefficient calculation submodule, used to determine the device trust coefficient of each involved data source based on the device status data of each involved data source; a second coefficient calculation submodule, used to determine the identity trust coefficient of each involved data source based on the identity verification results of each involved data source; a third coefficient calculation submodule, used to determine the data integrity coefficient of each involved data source based on the integrity verification results of each involved data source; a fourth coefficient calculation submodule, used to calculate the consistency coefficient of each involved data source based on the deviation data of each involved data source; and a weight fusion submodule, used to calculate the trust weight of the involved data source based on the device trust coefficient, identity trust coefficient, data integrity coefficient, and consistency coefficient of the same involved data source.

[0015] Further optionally, the responsibility allocation module includes: a feature pair generation submodule, used to combine the encrypted accident features of each involved data source with the corresponding trusted weights into input feature pairs; an input vector generation submodule, used to arrange the input feature pairs of all involved data sources in a preset order to construct a model input vector; and a responsibility ratio determination submodule, used to input the model input vector into a preset responsibility judgment model to obtain each responsible party and the corresponding responsibility ratio.

[0016] The above technical solution has the following beneficial effects: By hashing and storing multi-source data on the blockchain and retaining the original data locally, the privacy of all parties is protected under the premise of data immutability, thus solving the problems of centralized storage being easily tampered with and privacy leakage caused by plaintext sharing; by constructing a spatiotemporal consistency graph and calculating deviation data and abnormal data source markers, cross-verification of multi-vehicle and roadside data is realized, thereby eliminating deviations caused by single data source failures or forgery and improving the reliability of the basis for liability determination; by dynamically calculating the trust weight based on device status, identity verification, integrity verification, and deviation data, data sources of different quality have a differentiated impact on liability determination, thereby enhancing the robustness of the liability determination model to abnormal data; by inputting encrypted accident features under a secure multi-party computation framework and combining the trust weight with preset liability rules to calculate the liability ratio, all parties can complete collaborative determination without disclosing the original data, thus balancing data privacy and the accuracy of calculation results; by generating a liability determination report and storing it on the blockchain based on the liability ratio, trust weight, spatiotemporal consistency graph, and abnormal data source markers, the entire determination process is traceable and non-repudiable, thus forming a complete and reliable automated liability determination closed loop. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a flowchart of the multi-party collaborative autonomous driving traffic liability determination method provided in this embodiment of the invention; Figure 2 This is a flowchart of the spatiotemporal consistency map construction method provided in the embodiments of the present invention; Figure 3 This is a flowchart of the abnormal data marking method provided in the embodiments of the present invention; Figure 4 This is a flowchart of the trusted weight calculation method provided in the embodiments of the present invention; Figure 5 This is a flowchart of the responsibility ratio allocation method provided in the embodiments of the present invention; Figure 6 This is a schematic diagram of the multi-party collaborative autonomous driving traffic responsibility determination system provided in an embodiment of the present invention; Figure 7 This is a schematic diagram of the structure of a sub-module for map construction in the map construction module provided in an embodiment of the present invention; Figure 8This is a schematic diagram of the structure of the sub-module for marking abnormal data sources in the graph construction module provided in this embodiment of the invention; Figure 9 This is a schematic diagram of the weight calculation module provided in an embodiment of the present invention; Figure 10 This is a structural schematic diagram of the responsibility allocation module provided in an embodiment of the present invention.

[0019] Figure labeling: 100-Data acquisition module; 200-Summary storage module; 300-First verification module; 400-Second verification module; 500-Graph construction module; 5001-Spatiotemporal coordinate system construction submodule; 5002-Node addition submodule; 5003-Node edge addition submodule; 5004-Obstacle calculation submodule; 5005-Abnormal data source marking submodule; 600-Weight calculation module; 6001-First coefficient calculation submodule; 6002-Second coefficient calculation submodule; 6003-Third coefficient calculation submodule; 6004-Fourth coefficient calculation submodule; 6005-Weight fusion submodule; 700-Responsibility allocation module; 7001-Feature pair generation submodule; 7002-Input vector generation submodule; 7003-Responsibility ratio determination submodule; 800-Report generation module. Detailed Implementation

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

[0021] To address the problems of low efficiency, susceptibility to data tampering, insufficient privacy protection, lack of multi-source cross-validation, and lack of roadside data fusion in existing technologies for determining traffic liability in autonomous driving, this invention provides a multi-party collaborative autonomous driving traffic liability determination method. Figure 1 This is a flowchart of the multi-party collaborative autonomous driving traffic liability determination method provided in an embodiment of the present invention, such as... Figure 1 As shown, the method includes: S1. Real-time collection of raw data from various data sources; among which, the raw data corresponding to the vehicle data source is vehicle operation data, and the raw data corresponding to the roadside unit data source is roadside environmental data.

[0022] Data sources include vehicle data sources provided by the vehicle side and roadside unit data sources provided by the roadside. Vehicle data sources are deployed on autonomous vehicles or connected vehicles with data collection capabilities, while roadside unit data sources are deployed in intelligent roadside equipment (RSUs) on both sides of the road.

[0023] Vehicle data sources acquire vehicle operation data in real time through an onboard data acquisition system. The onboard data acquisition system includes: an onboard diagnostic interface (OBD), an inertial measurement unit (IMU), a global navigation satellite system (GNSS) receiver, wheel speed sensors, brake pressure sensors, a steering wheel angle sensor, an autonomous driving domain controller communication interface, and an onboard communication terminal (such as a C-V2X module).

[0024] The collected vehicle operation data includes at least one or more of the following: Motion data: vehicle speed, longitudinal acceleration, lateral acceleration, yaw rate, and heading angle; Control status data: brake pedal travel / opening, accelerator pedal opening, steering wheel angle, gear status; Autonomous driving system status data: autonomous driving mode on / off indicator, system takeover request indicator, fault codes (DTC, Diagnostic Trouble Code), and operating status of perception systems (camera / millimeter-wave radar / LiDAR); Positioning and time data: GNSS coordinates (longitude, latitude, altitude), positioning accuracy factor, UTC timestamp (accurate to milliseconds).

[0025] The data acquisition frequency is set according to the dynamic change characteristics of the data type: high-frequency acquisition is used for parameters that change rapidly, such as vehicle speed, acceleration, and braking status, for example, once every 10 to 100 milliseconds; lower-frequency acquisition is used for parameters that change slowly, such as once per second. All acquired data is accompanied by a uniform timestamp.

[0026] After collecting raw data, the vehicle data source reports to the automaker in real time through the data gateway. The automaker directly stores the raw data of the vehicle data source locally in encrypted form. Privacy computing nodes are deployed locally by the automaker for subsequent encrypted computing.

[0027] Roadside unit (RSU) data sources acquire real-time roadside environmental data through intelligent roadside units deployed at road intersections and along both sides of road sections. RSUs integrate high-resolution cameras, millimeter-wave radar, LiDAR, traffic light status interfaces, weather sensors, and edge computing units.

[0028] The collected roadside environmental data includes at least one or more of the following: Traffic participant trajectory data: real-time location, speed, direction of movement, and acceleration of all vehicles, pedestrians, and non-motorized vehicles within the RSU's sensing range; Traffic signal data: current traffic light phase (red / yellow / green), countdown time remaining, and planned traffic light timing scheme; Road environment data: lane markings (clear / worn), road surface adhesion coefficient (wet / dry / icy), construction area markings, visibility, weather conditions (rain / snow / fog); RSU self-status data: device ID, calibration validity period, sensor operating status, time synchronization status (whether it is synchronized with GNSS).

[0029] The RSU's acquisition frequency is coordinated with the vehicle data source. For example, it detects and tracks all targets within the perception range every 100 milliseconds to generate a target list; and generates a roadside environment data slice every second, with each slice containing multiple snapshots or trajectory fragments perceived within that second.

[0030] The RSU reports the collected raw data to the RSU operator. The reported raw data is also temporarily stored in encrypted form on the RSU operator's local machine. The RSU operator has deployed privacy computing nodes on its local machine for subsequent encrypted computation.

[0031] S2. Calculate the hash digest for the original data from each data source, obtain the corresponding comparison hash digest, and store it on the blockchain.

[0032] To facilitate evidence storage and verification, both the vehicle-side and roadside units report the raw data in segments to the corresponding agencies.

[0033] Specifically, the raw data is segmented into data chunks based on fixed time windows. The time window can be set according to the application scenario, such as 1 second, 5 seconds, or 10 seconds. All data collected within each time window constitutes a data chunk. For each data chunk, a cryptographic hash algorithm (such as SHA-256 or SM3) is used to calculate its hash value. All data chunks reported by each data source (a single vehicle or a single RSU) within each certain time period (e.g., 1 hour or 1 day) can be used to construct a Merkle hash tree. The root hash of the Merkle hash tree is used as the hash digest of all data chunks from that data source within that period.

[0034] Each data gateway (either the vehicle manufacturer's data gateway or the RSU operator's data gateway) sends the calculated comparison hash digest (i.e., the Merkle root hash) to the notarization service on the consortium blockchain. This consortium blockchain is jointly maintained by multiple participants, including vehicle manufacturers, testing agencies, insurance companies, and roadside unit operators. The notarization process involves the consortium blockchain achieving consensus among multiple nodes and then broadcasting the notarized content to all participants.

[0035] It should be noted that the original data itself (including the detailed content of each data shard) is not sent to the blockchain, but is stored in encrypted form in the local database of the respective data source organization (car manufacturer or RSU operator).

[0036] S3. When a traffic accident occurs, obtain the relevant original data of each data source involved in the accident within the time period of the accident, calculate the actual hash digest of each relevant original data, and perform integrity verification based on the actual hash digest and the corresponding comparison hash digest to obtain the integrity verification result.

[0037] After a traffic accident, the vehicle owner, the vehicle manufacturer, or the RSU operator can initiate a liability determination and claim rights application to start the liability determination process.

[0038] First, determine the time of the incident and locate the time period within which it occurs. This time period is determined based on the calculation cycle of the hash digest. For example, assuming the hash digest calculation cycle is every hour, the time period is the hour interval containing the incident. Furthermore, if the incident time is too close to the boundary of the current interval (e.g., less than 5 minutes away), the previous or next cycle of that interval boundary is also included in the time period to ensure complete coverage of information before and after the incident.

[0039] Based on the time and location of the accident (GPS coordinates or RSU coverage area), the relevant data sources are determined. These data sources include: all vehicles related to the accident (based on reported locations or RSU observation trajectories) and roadside units covering that location. The raw data corresponding to these data sources within the time period of the accident constitutes the relevant raw data for the current accident.

[0040] Furthermore, to aid in the judgment, the data source involved may also include surrounding vehicles that were driving normally within a certain period of time before and after the accident (such as 2 minutes before and after).

[0041] Each organization owning the data source involved will transmit the locally stored encrypted raw data from the period of the incident to its own privacy-preserving computation node (such as a TEE trusted execution environment). After decryption, the privacy node will recalculate the actual hash digest of the relevant raw data from the period of the incident using the same sharding granularity (e.g., 1 second) and the same hash digest calculation method (e.g., Merkle root hash calculation) as when calculating the hash digest for comparison. During the calculation process, the plaintext data only exists temporarily within the privacy node and is not exposed externally.

[0042] The accountability process involves querying the blockchain for the evidence storage records of the data source in question within the corresponding time period, obtaining the comparison hash digest of the on-chain evidence storage, and determining the actual hash digest corresponding to the data source in question. The comparison hash digest is compared with the actual hash digest. If they match, it is determined that the data source has not been tampered with, and the integrity verification result is passed. If there is a discrepancy within the time period of the incident, it is determined that the data has been tampered with or corrupted, the integrity verification result is failed, and the data source is recorded as an abnormal data source.

[0043] The integrity verification result is used for the trust weight calculation in subsequent steps. Data sources that fail the integrity verification will be assigned a very low trust weight or be directly excluded.

[0044] S4. Verify the identity based on the identity credentials of each data source involved, and obtain the identity verification result.

[0045] The identity credential is a verifiable credential (VC).

[0046] During the initialization phase, when a vehicle goes online, the automaker applies for a decentralized identity (DID) for it, while the RSU operator applies for a centralized identity for it when the roadside unit is deployed. The testing agency, as a trusted DID service provider, issues verifiable credentials (VCs) for both the vehicle and the roadside unit. The VC records attributes such as the data source's identity type, validity period, and public key information. The vehicle is then bound to its centralized identity (DID) for insurance purposes. The insurance information, along with the vehicle's centralized identity (DID) and the VC, is stored on the blockchain for subsequent claims processing and identity verification.

[0047] After an accident, the liability determination process calls the DID service of the testing agency to verify the validity of the identity credentials of all involved data sources (the vehicles involved and related RSUs), ensuring the validity of the identity credentials (whether they have expired or been cancelled). The DID service of the testing agency returns the verification result: if all verification items pass, the identity verification result is valid; otherwise, it is invalid, with the reason for failure (such as the VC has expired or been cancelled).

[0048] If the identity verification result is valid, the subsequent calculation of the trust weight will be positively supported; if the result is invalid, the data source will be marked as having an abnormal identity and will be given a very low weight or be directly excluded in the trust weight calculation.

[0049] S5. Obtain the encrypted incident characteristics based on the relevant original data of each involved data source, construct a spatiotemporal consistency map based on all encrypted incident characteristics, and calculate the deviation data and abnormal data source markers between each involved data source based on the spatiotemporal consistency map.

[0050] The accountability process automatically schedules cross-party privacy computing tasks based on the type of incident, ensuring that all participants do not exchange plaintext data, but only participate in encrypted collaborative computing within the privacy computing node.

[0051] In practical applications, each vehicle manufacturer involved in the incident provides its own vehicle-specific encrypted data, while the RSU operator provides relevant roadside encrypted data. Specifically, each participating party extracts key features related to accident liability determination from the encrypted data corresponding to the relevant original data in their local database. These features, known as encrypted accident features, include vehicle motion status (speed, acceleration, braking, steering, etc.), automated driving system status (takeover signs, etc.), vehicle equipment status (calibration validity period, malfunction status, etc.), and roadside environmental information (observation trajectory, traffic light status, road conditions, etc.), ensuring that the original feature values ​​are not disclosed to external parties.

[0052] Multi-source cross-validation is performed on the encrypted accident features provided by the data sources involved (vehicles, roadside units, etc.). By constructing a spatiotemporal consistency map, the degree of mutual corroboration between the data sources is quantified, thereby identifying abnormal data sources.

[0053] In the same traffic accident, data collected from different data sources have inherent physical consistency constraints in terms of time and space. For example, the trajectory of the vehicle involved should basically match the trajectory observed by the roadside unit; the relative positions and speed relationships between multiple vehicles should satisfy kinematic laws; and the motion state of the vehicles should logically match the status of traffic lights, road environmental conditions, etc.

[0054] The spatiotemporal consistency map integrates data from all the aforementioned data sources within a preset time period before and after the incident, establishing a unified reference system based on time and space. Within this reference system, data from each data source is mapped to corresponding spatiotemporal points or trajectories. By comparing the representations of different data sources at the same spatiotemporal point, the degree of deviation between them is calculated.

[0055] Specifically, map construction requires acquiring the operational data (position, speed, acceleration, etc.) of all vehicles involved in the accident during the time period, as well as all target trajectory data, traffic signal status, and road environment data observed by associated roadside units within that time window. Then, spatiotemporal alignment, association mapping, and map construction are performed sequentially.

[0056] Spatiotemporal alignment includes unifying all data to the same time reference (e.g., millisecond-level timestamps) and spatial reference (e.g., the WGS-84 coordinate system) to eliminate acquisition delays, positioning errors, and system biases between different devices; correlation mapping includes pairing the vehicle's self-reported trajectory with the trajectory observed by the roadside unit, associating the relative motion relationships between multiple vehicles, and logically associating vehicle motion with traffic light phases and road conditions; and graph construction includes using the time axis and spatial coordinates as the basis, and using the information from each data source as nodes or edges in the graph to form a computable multidimensional spatiotemporal relationship network.

[0057] Based on the constructed spatiotemporal consistency map, the encrypted accident characteristics of each involved data source are compared with the spatiotemporal benchmark in the map, and a consistency index between each data source and other data sources or environmental information is calculated. The consistency index includes at least: the deviation between vehicle self-reported trajectories and roadside unit observed trajectories, the mutual deviation between multi-vehicle self-reported trajectories, and the deviation between vehicle motion states and traffic environment logical constraints. Each involved data source obtains a set of quantified deviation data, reflecting the degree of inconsistency between its data and the results of multi-source cross-validation.

[0058] Preset deviation thresholds for various consistency indicators. When the deviation data of a data source exceeds the corresponding preset threshold, the data source is marked as an abnormal data source, and the abnormality type is recorded. Abnormal data sources are assigned lower weights or excluded in subsequent reliability weight calculations, while data sources with smaller deviations receive higher weights.

[0059] It should be noted that the multi-source data (vehicle self-reported trajectories, RSU observation data, etc.) required to construct the spatiotemporal consistency map are all processed in a secure multi-party computation framework or a trusted execution environment of each participant. When outputting the final result, some original data can be selectively labeled in the spatiotemporal consistency map according to actual needs.

[0060] S6. Calculate the trust weight of each data source involved based on the device status data, identity verification results, integrity verification results, and deviation data of each data source involved.

[0061] Equipment status data is one type of encrypted incident characteristic, and it includes the calibration validity period, fault records, and sensor operating status of the data source equipment. Data sources with good equipment status have higher basic credibility, while data sources with expired calibration or fault records have lower basic credibility.

[0062] In the identity verification results, data sources with valid identities receive positive weighting, while the trust weight of data sources with invalid, expired, or cancelled identities is significantly reduced or set to zero.

[0063] In the integrity verification results, the trust weight of data sources that pass the integrity verification (i.e., hash comparison is consistent) is maintained or enhanced, while the trust weight of data sources that fail the verification is significantly reduced or directly excluded.

[0064] The smaller the deviation value in the deviation data, the higher the degree of mutual corroboration between the data source and other independent data sources (such as other vehicles, roadside units), and the higher the credibility weight accordingly; the larger the deviation value, the lower the credibility weight, and when it exceeds the threshold, it is marked as an abnormal data source.

[0065] The system takes four types of inputs: device status data, identity verification results, integrity verification results, and deviation data. These are mapped to corresponding credibility components according to preset rules. The components are then combined (e.g., by weighted summation or product) to obtain the comprehensive credibility weight of each data source involved.

[0066] The credibility weight is output in numerical form. The higher the value, the higher the credibility of the data source and the greater its contribution to the subsequent responsibility determination; the lower the value, the smaller the impact.

[0067] As an optional implementation, the trust weight is obtained directly through a pre-trained trust assessment model. Specifically, the device status data, identity verification results, integrity verification results, and deviation data of each involved data source are used as input feature vectors and fed into a pre-trained machine learning model (such as logistic regression, gradient boosting trees, or neural networks). After forward computation, the model directly outputs the trust weight value of that data source. This model can be trained using multi-source information from historical accident data and trust labels annotated by experts, thereby achieving end-to-end assessment of the trustworthiness of data sources.

[0068] S7. Based on the encrypted incident characteristics, credibility weights, and preset liability assessment models of each data source involved, obtain the liability ratio of each responsible party.

[0069] The encrypted accident characteristics and corresponding trusted weights of each involved data source are input into a pre-defined liability assessment model. The model outputs the liability ratio of each responsible party (such as vehicle owner liability, vehicle manufacturer liability, third party liability, road environment liability, etc.), and the output results satisfy normalization constraints (e.g., the sum of the ratios of each responsible party is 100%).

[0070] It should be noted that the above calculation process is performed within a secure multi-party computation framework or trusted execution environment, and all intermediate results are encrypted or exist only in the protected environment. Each participating party cannot obtain the original characteristic data of the other parties, but can only obtain the final liability ratio result.

[0071] S8. Generate a responsibility determination report based on the responsibility ratio, credibility weight, spatiotemporal consistency graph, and abnormal data source markers, and store it on the blockchain.

[0072] The calculated liability ratios of each responsible party, the credibility weight of each involved data source, the spatiotemporal consistency map, and the markers of abnormal data sources are integrated into a liability determination report according to a preset format. This report contains traceable information covering the entire process from data verification and cross-validation to liability determination.

[0073] After the report is generated, the blockchain notarization service is invoked to upload the report content or its hash digest to the blockchain for notarization. Following consensus among multiple nodes on the consortium blockchain, the report becomes an immutable and permanent record, available for querying and verification by all participating parties (car manufacturers, insurance companies, testing institutions, car owners, etc.). Simultaneously, the report results can be sent to relevant parties via on-chain messages or offline notifications for subsequent claims and other business processes.

[0074] After the liability determination report is uploaded to the blockchain for evidence storage, the insurance company processes the claims based on the report content and uploads the claims results to the blockchain for evidence storage; the car manufacturer's liability determination service subscribes to claims result notification messages and notifies the car owner via SMS or APP.

[0075] As an optional implementation method, Figure 2 This is a flowchart of the spatiotemporal consistency map construction method provided in the embodiments of the present invention, such as... Figure 2 As shown, a spatiotemporal consistency map is constructed based on the characteristics of all ciphertext incidents, including: S501. Extract the timestamps and their corresponding spatial coordinates from the accident features of each encrypted message. Use the timestamps as the time reference and the spatial coordinates as the spatial reference to construct a unified spatiotemporal coordinate system.

[0076] For each data source involved (vehicle or roadside unit), the timestamp and spatial coordinates of each sampling point are extracted from the feature data. The timestamp uses a unified time base (such as GPS millisecond time), and the spatial coordinates use a unified geographic coordinate system (such as WGS-84 latitude and longitude coordinates or planar coordinates under a projected coordinate system). For vehicle data sources, the spatial coordinates are derived from the vehicle-mounted GNSS positioning module; for roadside unit data sources, the spatial coordinates are derived from the target location sensed by the RSU and after coordinate transformation.

[0077] Using an absolute timeline as the reference, the timestamps of each sampling point are mapped onto a unified timeline. A shared geographic coordinate system is used as the spatial reference to ensure that spatial coordinates from different sources are comparable within the same reference frame.

[0078] Within the privacy-preserving computing environment, a virtual, unified spatiotemporal coordinate system is established. This coordinate system consists of a time dimension and a spatial dimension: the time dimension is a continuous linear axis, with units of milliseconds; the spatial dimension is a two-dimensional or three-dimensional geographic coordinate axis, with units of meters or degrees. Each sampling point of each data source involved corresponds to a unique spatiotemporal point in this coordinate system. .

[0079] S502. In a unified spatiotemporal coordinate system, add nodes for the involved vehicles, roadside units, traffic signals, road environment, and accidents based on the characteristics of each encrypted accident.

[0080] Within the constructed unified spatiotemporal coordinate system, each data source involved and its related elements are abstracted into graph nodes.

[0081] Vehicle node involved in the incident: Based on the identifier of each vehicle involved in the incident (such as vehicle DID), a corresponding vehicle node is created in the coordinate system. Each vehicle node involved in the incident is associated with all spatiotemporal sampling points (position, velocity, acceleration, etc.) of that vehicle throughout the entire time window.

[0082] Roadside Unit Node: Create a roadside unit node based on the device identifier of the roadside unit, and associate it with all target trajectory data observed by the RSU within the time window.

[0083] Traffic signal node: Create a traffic signal node based on the traffic light signage at the accident location, and associate the phase change sequence (red, yellow, green and switching time) of the signal light within the time window.

[0084] Road environment nodes: Based on the environmental attributes of the accident section (such as the number of lanes, speed limit, construction signs, road surface adhesion coefficient, etc.), road environment nodes are created and associated with static or quasi-static environmental information.

[0085] Accident Node: Based on the time of the accident and accident location coordinates Create an accident node centered on the accident node and associate it with basic accident information (such as collision type and list of involved parties).

[0086] The locations of the involved vehicle nodes and roadside unit nodes change dynamically over time, while the locations of traffic signal nodes, road environment nodes, and accident nodes are relatively fixed.

[0087] S503. In a unified spatiotemporal coordinate system, construct vehicle trajectory edges, relative position edges, observation coverage edges, traffic light constraint edges, road environment influence edges, and collision association edges between nodes to obtain a spatiotemporal consistent graph. Among them, vehicle trajectory edges are the edges between the involved vehicle nodes corresponding to the same vehicle at different timestamps, relative position edges are the edges between the involved vehicle nodes corresponding to different vehicles, observation coverage edges are the edges between roadside unit nodes and related involved vehicles, traffic light constraint edges are the edges between traffic signal nodes and related involved vehicles, road environment influence edges are the edges between road environment nodes and related involved vehicle nodes, and collision association edges are the edges between accident nodes and related involved vehicles.

[0088] Within a unified spatiotemporal coordinate system, relationships between nodes are established based on their spatiotemporal attributes, forming a computable graph structure.

[0089] Vehicle trajectory edges: For the same vehicle involved in an incident, the vehicle nodes corresponding to different timestamps are connected sequentially in chronological order to form the vehicle's motion trajectory edges. Each edge is accompanied by attributes such as time difference, displacement vector, and average speed to describe the vehicle's motion path.

[0090] Relative position edges: Within the same timestamp or a very small time window, nodes of different vehicles involved in an incident are connected to form relative position edges. Each edge includes attributes such as the distance between the two vehicles, their relative speed, and their azimuth angle, used to describe the spatial relationship between the vehicles.

[0091] Observation coverage edge: Connect roadside unit nodes to the involved vehicle nodes within their observation range to form an observation coverage edge. Each edge includes attributes such as the vehicle's position, speed, observation time, and perception confidence level observed by the RSU, used to compare the consistency between vehicle self-reported data and roadside observation data.

[0092] Traffic light constraint edges: These connect traffic signal nodes to the involved vehicle nodes within their control range, forming traffic light constraint edges. Each edge includes attributes such as the traffic light phase, countdown, and actual vehicle behavior (e.g., whether the vehicle stopped or ran a red light) when the vehicle passed through the intersection, used to determine whether the vehicle obeyed traffic signals.

[0093] Road environment impact edge: Connect road environment nodes with the nodes of the vehicles involved in the incident traveling on that road segment to form a road environment impact edge. Each edge includes attributes such as the speed limit, curvature, road surface adhesion coefficient, and construction status of the road segment, used to determine whether the vehicle behavior matches the road environment.

[0094] Collision-related edges: These connect the accident node to the nodes of all involved vehicles, forming collision-related edges. Each edge includes attributes such as the vehicle's speed, acceleration, collision angle, and degree of damage at the time of the accident, used to associate the consequences of the accident with the responsibilities of each party.

[0095] Once the above six types of edges are constructed, they together with the various types of nodes that have been added constitute a spatiotemporally consistent graph.

[0096] The graph construction process is completed within a privacy-preserving computing environment (such as a TEE environment or MPC framework). It can output only the relative attribute data of all edges without outputting the original data, or selectively output some of the original data as edge annotation data according to the actual situation.

[0097] As an optional implementation method, Figure 3 This is a flowchart of the abnormal data marking method provided in the embodiments of the present invention, such as... Figure 3As shown, the deviation data and abnormal data source markers between the involved data sources are calculated based on the spatiotemporal consistency map, including: S504. For each data source involved, the motion trajectory of the data source involved is compared with the corresponding motion trajectories of other data sources involved to obtain the deviation data.

[0098] Using the spatiotemporal scope of the accident as a boundary, the self-reported movement trajectory of the vehicle involved and the observed movement trajectory of the roadside unit are obtained. Further trajectory comparison is then performed based on these results. For each vehicle involved in the incident, its self-reported trajectory is compared hourly with the observed trajectory of each RSU covering the vehicle to generate one or more "vehicle-RSU" deviation sequences; its self-reported trajectory is also compared hourly with the self-reported trajectories of other vehicles involved in the incident to generate "vehicle-vehicle" deviation sequences.

[0099] For each roadside unit, its observed motion trajectory for a certain vehicle is compared with the self-reported motion trajectory of that vehicle to generate an "RSU-vehicle" deviation sequence; its observed trajectory for the same vehicle is compared with the observed trajectories of other RSUs (if any) for that vehicle to generate an "RSU-RSU" deviation sequence.

[0100] The deviation sequences generated by the above comparisons collectively constitute the deviation data for each data source involved. The instantaneous deviation value in each deviation sequence reflects the degree of consistency of that data source at different time points and under different comparison benchmarks.

[0101] S505. Compare the deviation data of each involved vehicle with the preset deviation threshold. When the deviation data exceeds the preset deviation threshold, mark the involved data source as an abnormal data source.

[0102] For each type of deviation, a corresponding threshold is preset (e.g., a position deviation threshold of 5 meters, a speed deviation threshold of 10 km / h). For each data source involved (vehicle or roadside unit), anomaly determination is made by combining all its deviation sequences.

[0103] In one optional implementation, a single-dimensional anomaly determination is adopted. For any deviation sequence, if the instantaneous deviation value in the sequence exceeds a preset proportion (e.g., 10%) and exceeds a threshold, or if the statistical characteristics (mean, maximum value) of the sequence exceed the threshold, then the data source is determined to have an anomaly in the comparison dimension.

[0104] In another alternative implementation, a multi-dimensional cross-judgment is adopted. If a data source is judged as abnormal in multiple independent comparison dimensions (e.g., comparison with multiple different RSUs, comparison with multiple other vehicles), then the data source is marked as an abnormal data source.

[0105] As an optional implementation method, Figure 4 This is a flowchart of the trusted weight calculation method provided in the embodiments of the present invention, such as... Figure 4 As shown, based on the device status data, identity verification results, integrity verification results, and deviation data of each data source involved, the trust weight of each data source involved is calculated, including: S601. Based on the device status data of each data source involved, determine the device reliability coefficient of each data source involved.

[0106] Assess the reliability of the hardware and sensors of the data source involved (vehicle or roadside unit) and quantify it as a device reliability coefficient. Device status data includes, but is not limited to: sensor calibration status, device fault code records, etc.

[0107] The device stores data in the database of the car manufacturer or RSU operator, and it is stored locally in an encrypted form. Data processing can be achieved through privacy-preserving computation.

[0108] According to preset rules, device status data is mapped to a device confidence coefficient between 0 and 1.

[0109] Mapping rule example: Calibration was effective and no faults were recorded: the equipment reliability coefficient is 1.0; Calibration was valid but fault records exist: the equipment reliability coefficient is 0.5; Calibration invalid and no fault record: Equipment reliability coefficient is 0.3; Invalid calibration and fault records: Equipment reliability coefficient is 0.

[0110] S602. Based on the identity verification results of each data source involved, determine the identity credibility coefficient of each data source involved.

[0111] The identity verification result includes at least two states: valid (VC signature correct, not expired, not cancelled) and invalid (VC expired, cancelled, signature mismatch, or identity credential missing). The verification state is mapped to a coefficient between 0 and 1 according to preset rules. For example, when the identity verification result is valid, the identity credibility coefficient = 1; when the identity verification result is invalid, the identity credibility coefficient = 0.

[0112] If the identity verification result contains intermediate states (such as about to expire or within the grace period), an intermediate coefficient value (such as 0.8) can be set accordingly, but at least the two basic states of valid and invalid should be distinguished.

[0113] S603. Based on the integrity verification results of each data source involved, determine the data integrity coefficient of each data source involved.

[0114] The integrity verification result includes at least two states: pass (the on-chain notarized hash matches the actual calculated hash, and the data has not been tampered with) and fail (the hash is inconsistent or the data is missing). The verification state is mapped to a coefficient between 0 and 1 according to preset rules. For example, when the integrity verification result is pass, the data integrity coefficient = 1.0; when the integrity verification result is fail, the data integrity coefficient = 0.

[0115] If there are intermediate situations during the verification process, such as some data fragments being missing but the whole data still being partially usable (e.g., the missing percentage is lower than the preset threshold), an intermediate coefficient (e.g., 0.5) can be set, but at least the two basic states of passing and failing should be distinguished.

[0116] S604. Calculate the consistency coefficient of each data source involved based on the deviation data of each data source involved.

[0117] For each data source involved, a consistency coefficient between 0 and 1 is calculated based on its deviation data. The smaller the deviation, the higher the consistency coefficient; the larger the deviation, the lower the consistency coefficient.

[0118] The specific mapping method can be any of the following: calculate the mean or maximum value of the deviation sequence, compare it with the preset deviation threshold, and map it to a coefficient according to a piecewise linear function or an exponential decay function. For example, the coefficient is 1 when the deviation mean is 0, the coefficient is 0.5 when the deviation mean reaches the threshold, and the coefficient approaches 0 after exceeding the threshold; count the proportion of points in the deviation sequence that exceed the preset threshold, and the consistency coefficient = 1 - the proportion of exceeding the limit (or use a smoother function).

[0119] For multiple deviation items in the deviation data from the same data source, a weighted sum can be performed to obtain a final consistency coefficient.

[0120] S605. Calculate the trust weight of the data source involved based on the device trust coefficient, identity trust coefficient, data integrity coefficient, and consistency coefficient of the same data source involved.

[0121] The four coefficients are combined into a comprehensive confidence weight. One of the following three methods can be used: The product method involves multiplying the four coefficients. If any coefficient is 0, the weight is 0; if all coefficients are 1, the weight is 1. This method is sensitive to low scores; the weight is only high when all dimensions are good.

[0122] The weighted summation method involves assigning a preset weight to each coefficient and then calculating the weighted sum. Each coefficient can be compensated independently, making it suitable for scenarios where the importance of different dimensions is clearly distinguished.

[0123] The model-based approach uses four coefficients as input feature vectors, which are then fed into a pre-trained machine learning model (such as logistic regression or a small neural network). The model outputs confidence weights. The model can be derived by learning the non-linear relationship between each coefficient and the true confidence level of the data source from historical data.

[0124] As an optional implementation method, Figure 5 This is a flowchart of the responsibility ratio allocation method provided in the embodiments of the present invention, such as... Figure 5 As shown, based on the encrypted incident characteristics, credibility weights, and preset liability assessment models of each involved data source, the liability ratios of each responsible party and their respective responsibilities are obtained, including: S701. Combine the encrypted incident features of each involved data source with the corresponding trusted weights to form input feature pairs.

[0125] For each data source involved, its encrypted incident feature vector is combined with trusted weights. The combination can be done by either adding the weights as an additional dimension to the feature vector, i.e., constructing a concatenated extended vector; or by storing the weights separately and establishing a mapping relationship with the feature vector to form a feature pair.

[0126] S702. Arrange the input feature pairs of all involved data sources in a preset order to construct the model input vector.

[0127] A fixed sorting method is pre-agreed upon, such as sorting by the type of data source involved (vehicles first, roadside units second) or by the identifier of the data source in ascending or descending order. All participants use the same sorting rule before model computation to ensure that the dimensions of the input vectors are consistent.

[0128] For each feature pair, all input feature pairs are concatenated in a preset order to form a complete model input vector.

[0129] The completed model input vector exists in encrypted form and is input into the pre-defined judgment model for forward computation. The entire permutation and construction process is completed within a privacy-preserving computation environment.

[0130] S703. Input the model input vector into the preset responsibility judgment model to obtain each responsible party and the corresponding responsibility ratio.

[0131] A liability determination model is a pre-trained, computable model that accepts a fixed-dimensional input vector and outputs a probability distribution or proportion of each responsible party. Examples include logistic regression, a softmax classifier, or a small neural network, with model parameters trained using historical accident data.

[0132] The model outputs the liability ratio of each party, for example: car owner 52%, car manufacturer 30%, third party 10%, and road environment 8%. The output can be plaintext (viewable after being shared by all parties) or encryptedtext (viewable after being decrypted by other participants).

[0133] This invention also provides a multi-party collaborative autonomous driving traffic liability determination system. Figure 6 This is a schematic diagram of the multi-party collaborative autonomous driving traffic liability determination system provided in an embodiment of the present invention, as shown below. Figure 6 As shown, the system includes: The data acquisition module 100 is used to collect raw data from various data sources in real time; among them, the raw data corresponding to the vehicle data source is vehicle operation data, and the raw data corresponding to the roadside unit data source is roadside environmental data.

[0134] Data sources include vehicle data sources provided by the vehicle side and roadside unit data sources provided by the roadside. Vehicle data sources are deployed on autonomous vehicles or connected vehicles with data collection capabilities, while roadside unit data sources are deployed in intelligent roadside equipment (RSUs) on both sides of the road.

[0135] Vehicle data sources acquire vehicle operation data in real time through an onboard data acquisition system. The onboard data acquisition system includes: an onboard diagnostic interface (OBD), an inertial measurement unit (IMU), a global navigation satellite system (GNSS) receiver, wheel speed sensors, brake pressure sensors, a steering wheel angle sensor, an autonomous driving domain controller communication interface, and an onboard communication terminal (such as a C-V2X module).

[0136] The collected vehicle operation data includes at least one or more of the following: Motion data: vehicle speed, longitudinal acceleration, lateral acceleration, yaw rate, and heading angle; Control status data: brake pedal travel / opening, accelerator pedal opening, steering wheel angle, gear status; Autonomous driving system status data: autonomous driving mode on / off indicator, system takeover request indicator, fault codes (DTC, Diagnostic Trouble Code), and operating status of perception systems (camera / millimeter-wave radar / LiDAR); Positioning and time data: GNSS coordinates (longitude, latitude, altitude), positioning accuracy factor, UTC timestamp (accurate to milliseconds).

[0137] The data acquisition frequency is set according to the dynamic change characteristics of the data type: high-frequency acquisition is used for parameters that change rapidly, such as vehicle speed, acceleration, and braking status, for example, once every 10 to 100 milliseconds; lower-frequency acquisition is used for parameters that change slowly, such as once per second. All acquired data is accompanied by a uniform timestamp.

[0138] After collecting raw data, the vehicle data source reports to the automaker in real time through the data gateway. The automaker directly stores the raw data of the vehicle data source locally in encrypted form. Privacy computing nodes are deployed locally by the automaker for subsequent encrypted computing.

[0139] Roadside unit (RSU) data sources acquire real-time roadside environmental data through intelligent roadside units deployed at road intersections and along both sides of road sections. RSUs integrate high-resolution cameras, millimeter-wave radar, LiDAR, traffic light status interfaces, weather sensors, and edge computing units.

[0140] The collected roadside environmental data includes at least one or more of the following: Traffic participant trajectory data: real-time location, speed, direction of movement, and acceleration of all vehicles, pedestrians, and non-motorized vehicles within the RSU's sensing range; Traffic signal data: current traffic light phase (red / yellow / green), countdown time remaining, and planned traffic light timing scheme; Road environment data: lane markings (clear / worn), road surface adhesion coefficient (wet / dry / icy), construction area markings, visibility, weather conditions (rain / snow / fog); RSU self-status data: device ID, calibration validity period, sensor operating status, time synchronization status (whether it is synchronized with GNSS).

[0141] The RSU's acquisition frequency is coordinated with the vehicle data source. For example, it detects and tracks all targets within the perception range every 100 milliseconds to generate a target list; and generates a roadside environment data slice every second, with each slice containing multiple snapshots or trajectory fragments perceived within that second.

[0142] The RSU reports the collected raw data to the RSU operator. The reported raw data is also temporarily stored in encrypted form on the RSU operator's local machine. The RSU operator has deployed privacy computing nodes on its local machine for subsequent encrypted computation.

[0143] The hash digest module 200 is used to calculate the hash digest of the original data from each data source, obtain the corresponding comparison hash digest, and store it on the blockchain.

[0144] To facilitate evidence storage and verification, both the vehicle-side and roadside units report the raw data in segments to the corresponding agencies.

[0145] Specifically, the raw data is segmented into data chunks based on fixed time windows. The time window can be set according to the application scenario, such as 1 second, 5 seconds, or 10 seconds. All data collected within each time window constitutes a data chunk. For each data chunk, a cryptographic hash algorithm (such as SHA-256 or SM3) is used to calculate its hash value. All data chunks reported by each data source (a single vehicle or a single RSU) within each certain time period (e.g., 1 hour or 1 day) can be used to construct a Merkle hash tree. The root hash of the Merkle hash tree is used as the hash digest of all data chunks from that data source within that period.

[0146] Each data gateway (either the vehicle manufacturer's data gateway or the RSU operator's data gateway) sends the calculated comparison hash digest (i.e., the Merkle root hash) to the notarization service on the consortium blockchain. This consortium blockchain is jointly maintained by multiple participants, including vehicle manufacturers, testing agencies, insurance companies, and roadside unit operators. The notarization process involves the consortium blockchain achieving consensus among multiple nodes and then broadcasting the notarized content to all participants.

[0147] It should be noted that the original data itself (including the detailed content of each data shard) is not sent to the blockchain, but is stored in encrypted form in the local database of the respective data source organization (car manufacturer or RSU operator).

[0148] The first verification module 300 is used to obtain the relevant original data of each data source involved in the accident within the time period of the accident when a traffic accident occurs, calculate the actual hash digest of each relevant original data, and perform integrity verification based on the actual hash digest and the corresponding comparison hash digest to obtain the integrity verification result.

[0149] After a traffic accident, the vehicle owner, the vehicle manufacturer, or the RSU operator can initiate a liability determination and claim rights application to start the liability determination process.

[0150] First, determine the time of the incident and locate the time period within which it occurs. This time period is determined based on the calculation cycle of the hash digest. For example, assuming the hash digest calculation cycle is every hour, the time period is the hour interval containing the incident. Furthermore, if the incident time is too close to the boundary of the current interval (e.g., less than 5 minutes away), the previous or next cycle of that interval boundary is also included in the time period to ensure complete coverage of information before and after the incident.

[0151] Based on the time and location of the accident (GPS coordinates or RSU coverage area), the relevant data sources are determined. These data sources include: all vehicles related to the accident (based on reported locations or RSU observation trajectories) and roadside units covering that location. The raw data corresponding to these data sources within the time period of the accident constitutes the relevant raw data for the current accident.

[0152] Furthermore, to aid in the judgment, the data source involved may also include surrounding vehicles that were driving normally within a certain period of time before and after the accident (such as 2 minutes before and after).

[0153] Each organization owning the data source involved will transmit the locally stored encrypted raw data from the period of the incident to its own privacy-preserving computation node (such as a TEE trusted execution environment). After decryption, the privacy node will recalculate the actual hash digest of the relevant raw data from the period of the incident using the same sharding granularity (e.g., 1 second) and the same hash digest calculation method (e.g., Merkle root hash calculation) as when calculating the hash digest for comparison. During the calculation process, the plaintext data only exists temporarily within the privacy node and is not exposed externally.

[0154] The accountability process involves querying the blockchain for the evidence storage records of the data source in question within the corresponding time period, obtaining the comparison hash digest of the on-chain evidence storage, and determining the actual hash digest corresponding to the data source in question. The comparison hash digest is compared with the actual hash digest. If they match, it is determined that the data source has not been tampered with, and the integrity verification result is passed. If there is a discrepancy within the time period of the incident, it is determined that the data has been tampered with or corrupted, the integrity verification result is failed, and the data source is recorded as an abnormal data source.

[0155] The integrity verification result is used for the trust weight calculation in subsequent steps. Data sources that fail the integrity verification will be assigned a very low trust weight or be directly excluded.

[0156] The second verification module 400 is used to verify the identity based on the identity credentials of each data source involved and obtain the identity verification result.

[0157] The identity credential is a verifiable credential (VC).

[0158] During the initialization phase, when a vehicle goes online, the automaker applies for a decentralized identity (DID) for it, while the RSU operator applies for a centralized identity for it when the roadside unit is deployed. The testing agency, as a trusted DID service provider, issues verifiable credentials (VCs) for both the vehicle and the roadside unit. The VC records attributes such as the data source's identity type, validity period, and public key information. The vehicle is then bound to its centralized identity (DID) for insurance purposes. The insurance information, along with the vehicle's centralized identity (DID) and the VC, is stored on the blockchain for subsequent claims processing and identity verification.

[0159] After an accident, the liability determination process calls the DID service of the testing agency to verify the validity of the identity credentials of all involved data sources (the vehicles involved and related RSUs), ensuring the validity of the identity credentials (whether they have expired or been cancelled). The DID service of the testing agency returns the verification result: if all verification items pass, the identity verification result is valid; otherwise, it is invalid, with the reason for failure (such as the VC has expired or been cancelled).

[0160] If the identity verification result is valid, the subsequent calculation of the trust weight will be positively supported; if the result is invalid, the data source will be marked as having an abnormal identity and will be given a very low weight or be directly excluded in the trust weight calculation.

[0161] The graph construction module 500 is used to obtain the encrypted incident characteristics based on the relevant original data of each involved data source, construct a spatiotemporal consistency graph based on all encrypted incident characteristics, and calculate the deviation data and abnormal data source markers between each involved data source based on the spatiotemporal consistency graph.

[0162] The accountability process automatically schedules cross-party privacy computing tasks based on the type of incident, ensuring that all participants do not exchange plaintext data, but only participate in encrypted collaborative computing within the privacy computing node.

[0163] In practical applications, each vehicle manufacturer involved in the incident provides its own vehicle-specific encrypted data, while the RSU operator provides relevant roadside encrypted data. Specifically, each participating party extracts key features related to accident liability determination from the encrypted data corresponding to the relevant original data in their local database. These features, known as encrypted accident features, include vehicle motion status (speed, acceleration, braking, steering, etc.), automated driving system status (takeover signs, etc.), vehicle equipment status (calibration validity period, malfunction status, etc.), and roadside environmental information (observation trajectory, traffic light status, road conditions, etc.), ensuring that the original feature values ​​are not disclosed to external parties.

[0164] Multi-source cross-validation is performed on the encrypted accident features provided by the data sources involved (vehicles, roadside units, etc.). By constructing a spatiotemporal consistency map, the degree of mutual corroboration between the data sources is quantified, thereby identifying abnormal data sources.

[0165] In the same traffic accident, data collected from different data sources have inherent physical consistency constraints in terms of time and space. For example, the trajectory of the vehicle involved should basically match the trajectory observed by the roadside unit; the relative positions and speed relationships between multiple vehicles should satisfy kinematic laws; and the motion state of the vehicles should logically match the status of traffic lights, road environmental conditions, etc.

[0166] The spatiotemporal consistency map integrates data from all the aforementioned data sources within a preset time period before and after the incident, establishing a unified reference system based on time and space. Within this reference system, data from each data source is mapped to corresponding spatiotemporal points or trajectories. By comparing the representations of different data sources at the same spatiotemporal point, the degree of deviation between them is calculated.

[0167] Specifically, map construction requires acquiring the operational data (position, speed, acceleration, etc.) of all vehicles involved in the accident during the time period, as well as all target trajectory data, traffic signal status, and road environment data observed by associated roadside units within that time window. Then, spatiotemporal alignment, association mapping, and map construction are performed sequentially.

[0168] Spatiotemporal alignment includes unifying all data to the same time reference (e.g., millisecond-level timestamps) and spatial reference (e.g., the WGS-84 coordinate system) to eliminate acquisition delays, positioning errors, and system biases between different devices; correlation mapping includes pairing the vehicle's self-reported trajectory with the trajectory observed by the roadside unit, associating the relative motion relationships between multiple vehicles, and logically associating vehicle motion with traffic light phases and road conditions; and graph construction includes using the time axis and spatial coordinates as the basis, and using the information from each data source as nodes or edges in the graph to form a computable multidimensional spatiotemporal relationship network.

[0169] Based on the constructed spatiotemporal consistency map, the encrypted accident characteristics of each involved data source are compared with the spatiotemporal benchmark in the map, and a consistency index between each data source and other data sources or environmental information is calculated. The consistency index includes at least: the deviation between vehicle self-reported trajectories and roadside unit observed trajectories, the mutual deviation between multi-vehicle self-reported trajectories, and the deviation between vehicle motion states and traffic environment logical constraints. Each involved data source obtains a set of quantified deviation data, reflecting the degree of inconsistency between its data and the results of multi-source cross-validation.

[0170] Preset deviation thresholds for various consistency indicators. When the deviation data of a data source exceeds the corresponding preset threshold, the data source is marked as an abnormal data source, and the abnormality type is recorded. Abnormal data sources are assigned lower weights or excluded in subsequent reliability weight calculations, while data sources with smaller deviations receive higher weights.

[0171] It should be noted that the multi-source data (vehicle self-reported trajectories, RSU observation data, etc.) required to construct the spatiotemporal consistency map are all processed in a secure multi-party computation framework or a trusted execution environment of each participant. When outputting the final result, some original data can be selectively labeled in the spatiotemporal consistency map according to actual needs.

[0172] The weight calculation module 600 is used to calculate the trust weight of each data source involved in the incident based on the device status data, identity verification results, integrity verification results, and deviation data of each data source involved.

[0173] Equipment status data is one type of encrypted incident characteristic, and it includes the calibration validity period, fault records, and sensor operating status of the data source equipment. Data sources with good equipment status have higher basic credibility, while data sources with expired calibration or fault records have lower basic credibility.

[0174] In the identity verification results, data sources with valid identities receive positive weighting, while the trust weight of data sources with invalid, expired, or cancelled identities is significantly reduced or set to zero.

[0175] In the integrity verification results, the trust weight of data sources that pass the integrity verification (i.e., hash comparison is consistent) is maintained or enhanced, while the trust weight of data sources that fail the verification is significantly reduced or directly excluded.

[0176] The smaller the deviation value in the deviation data, the higher the degree of mutual corroboration between the data source and other independent data sources (such as other vehicles, roadside units), and the higher the credibility weight accordingly; the larger the deviation value, the lower the credibility weight, and when it exceeds the threshold, it is marked as an abnormal data source.

[0177] The system takes four types of inputs: device status data, identity verification results, integrity verification results, and deviation data. These are mapped to corresponding credibility components according to preset rules. The components are then combined (e.g., by weighted summation or product) to obtain the comprehensive credibility weight of each data source involved.

[0178] The credibility weight is output in numerical form. The higher the value, the higher the credibility of the data source and the greater its contribution to the subsequent responsibility determination; the lower the value, the smaller the impact.

[0179] As an optional implementation, the trust weight is obtained directly through a pre-trained trust assessment model. Specifically, the device status data, identity verification results, integrity verification results, and deviation data of each involved data source are used as input feature vectors and fed into a pre-trained machine learning model (such as logistic regression, gradient boosting trees, or neural networks). After forward computation, the model directly outputs the trust weight value of that data source. This model can be trained using multi-source information from historical accident data and trust labels annotated by experts, thereby achieving end-to-end assessment of the trustworthiness of data sources.

[0180] The responsibility allocation module 700 is used to obtain the responsibility ratio of each responsible party based on the encrypted accident characteristics, credibility weights and preset responsibility judgment models of each involved data source.

[0181] The encrypted accident characteristics and corresponding trusted weights of each involved data source are input into a pre-defined liability assessment model. The model outputs the liability ratio of each responsible party (such as vehicle owner liability, vehicle manufacturer liability, third party liability, road environment liability, etc.), and the output results satisfy normalization constraints (e.g., the sum of the ratios of each responsible party is 100%).

[0182] It should be noted that the above calculation process is performed within a secure multi-party computation framework or trusted execution environment, and all intermediate results are encrypted or exist only in the protected environment. Each participating party cannot obtain the original characteristic data of the other parties, but can only obtain the final liability ratio result.

[0183] The report generation module 800 is used to generate a responsibility determination report and store it on the blockchain based on the responsibility ratio, credibility weight, spatiotemporal consistency graph and abnormal data source markers.

[0184] The calculated liability ratios of each responsible party, the credibility weight of each involved data source, the spatiotemporal consistency map, and the markers of abnormal data sources are integrated into a liability determination report according to a preset format. This report contains traceable information covering the entire process from data verification and cross-validation to liability determination.

[0185] After the report is generated, the blockchain notarization service is invoked to upload the report content or its hash digest to the blockchain for notarization. Following consensus among multiple nodes on the consortium blockchain, the report becomes an immutable and permanent record, available for querying and verification by all participating parties (car manufacturers, insurance companies, testing institutions, car owners, etc.). Simultaneously, the report results can be sent to relevant parties via on-chain messages or offline notifications for subsequent claims and other business processes.

[0186] After the liability determination report is uploaded to the blockchain for evidence storage, the insurance company processes the claims based on the report content and uploads the claims results to the blockchain for evidence storage; the car manufacturer's liability determination service subscribes to claims result notification messages and notifies the car owner via SMS or APP.

[0187] As an optional implementation method, Figure 7 This is a schematic diagram of the structure of the sub-module used for map construction in the map construction module provided in this embodiment of the invention, such as... Figure 7 As shown, the map construction module 500 includes: The spatiotemporal coordinate system construction submodule 5001 is used to extract the timestamps and their corresponding spatial coordinates from the characteristics of each encrypted incident. Using the timestamps as the time reference and the spatial coordinates as the spatial reference, a unified spatiotemporal coordinate system is constructed.

[0188] For each data source involved (vehicle or roadside unit), the timestamp and spatial coordinates of each sampling point are extracted from the feature data. The timestamp uses a unified time base (such as GPS millisecond time), and the spatial coordinates use a unified geographic coordinate system (such as WGS-84 latitude and longitude coordinates or planar coordinates under a projected coordinate system). For vehicle data sources, the spatial coordinates are derived from the vehicle-mounted GNSS positioning module; for roadside unit data sources, the spatial coordinates are derived from the target location sensed by the RSU and after coordinate transformation.

[0189] Using an absolute timeline as the reference, the timestamps of each sampling point are mapped onto a unified timeline. A shared geographic coordinate system is used as the spatial reference to ensure that spatial coordinates from different sources are comparable within the same reference frame.

[0190] Within the privacy-preserving computing environment, a virtual, unified spatiotemporal coordinate system is established. This coordinate system consists of a time dimension and a spatial dimension: the time dimension is a continuous linear axis, with units of milliseconds; the spatial dimension is a two-dimensional or three-dimensional geographic coordinate axis, with units of meters or degrees. Each sampling point of each data source involved corresponds to a unique spatiotemporal point in this coordinate system. .

[0191] The node addition submodule 5002 is used to add involved vehicle nodes, roadside unit nodes, traffic signal nodes, road environment nodes, and accident nodes in a unified spatiotemporal coordinate system based on the characteristics of each encrypted accident.

[0192] Within the constructed unified spatiotemporal coordinate system, each data source involved and its related elements are abstracted into graph nodes.

[0193] Vehicle node involved in the incident: Based on the identifier of each vehicle involved in the incident (such as vehicle DID), a corresponding vehicle node is created in the coordinate system. Each vehicle node involved in the incident is associated with all spatiotemporal sampling points (position, velocity, acceleration, etc.) of that vehicle throughout the entire time window.

[0194] Roadside Unit Node: Create a roadside unit node based on the device identifier of the roadside unit, and associate it with all target trajectory data observed by the RSU within the time window.

[0195] Traffic signal node: Create a traffic signal node based on the traffic light signage at the accident location, and associate the phase change sequence (red, yellow, green and switching time) of the signal light within the time window.

[0196] Road environment nodes: Based on the environmental attributes of the accident section (such as the number of lanes, speed limit, construction signs, road surface adhesion coefficient, etc.), road environment nodes are created and associated with static or quasi-static environmental information.

[0197] Accident Node: Based on the time of the accident and accident location coordinates Create an accident node centered on the accident node and associate it with basic accident information (such as collision type and list of involved parties).

[0198] The locations of the involved vehicle nodes and roadside unit nodes change dynamically over time, while the locations of traffic signal nodes, road environment nodes, and accident nodes are relatively fixed.

[0199] A submodule 5003 is added to the node edge to construct vehicle trajectory edges, relative position edges, observation coverage edges, traffic light constraint edges, road environment influence edges, and collision association edges between nodes in a unified spatiotemporal coordinate system, thereby obtaining a spatiotemporally consistent map. Among them, vehicle trajectory edges are the edges between the involved vehicle nodes corresponding to the same vehicle at different timestamps, relative position edges are the edges between the involved vehicle nodes corresponding to different vehicles, observation coverage edges are the edges between roadside unit nodes and related involved vehicles, traffic light constraint edges are the edges between traffic signal nodes and related involved vehicles, road environment influence edges are the edges between road environment nodes and related involved vehicle nodes, and collision association edges are the edges between accident nodes and related involved vehicles.

[0200] Within a unified spatiotemporal coordinate system, relationships between nodes are established based on their spatiotemporal attributes, forming a computable graph structure.

[0201] Vehicle trajectory edges: For the same vehicle involved in an incident, the vehicle nodes corresponding to different timestamps are connected sequentially in chronological order to form the vehicle's motion trajectory edges. Each edge is accompanied by attributes such as time difference, displacement vector, and average speed to describe the vehicle's motion path.

[0202] Relative position edges: Within the same timestamp or a very small time window, nodes of different vehicles involved in an incident are connected to form relative position edges. Each edge includes attributes such as the distance between the two vehicles, their relative speed, and their azimuth angle, used to describe the spatial relationship between the vehicles.

[0203] Observation coverage edge: Connect roadside unit nodes to the involved vehicle nodes within their observation range to form an observation coverage edge. Each edge includes attributes such as the vehicle's position, speed, observation time, and perception confidence level observed by the RSU, used to compare the consistency between vehicle self-reported data and roadside observation data.

[0204] Traffic light constraint edges: These connect traffic signal nodes to the involved vehicle nodes within their control range, forming traffic light constraint edges. Each edge includes attributes such as the traffic light phase, countdown, and actual vehicle behavior (e.g., whether the vehicle stopped or ran a red light) when the vehicle passed through the intersection, used to determine whether the vehicle obeyed traffic signals.

[0205] Road environment impact edge: Connect road environment nodes with the nodes of the vehicles involved in the incident traveling on that road segment to form a road environment impact edge. Each edge includes attributes such as the speed limit, curvature, road surface adhesion coefficient, and construction status of the road segment, used to determine whether the vehicle behavior matches the road environment.

[0206] Collision-related edges: These connect the accident node to the nodes of all involved vehicles, forming collision-related edges. Each edge includes attributes such as the vehicle's speed, acceleration, collision angle, and degree of damage at the time of the accident, used to associate the consequences of the accident with the responsibilities of each party.

[0207] Once the above six types of edges are constructed, they together with the various types of nodes that have been added constitute a spatiotemporally consistent graph.

[0208] The graph construction process is completed within a privacy-preserving computing environment (such as a TEE environment or MPC framework). It can output only the relative attribute data of all edges without outputting the original data, or selectively output some of the original data as edge annotation data according to the actual situation.

[0209] As an optional implementation method, Figure 8 This is a schematic diagram of the structure of the submodule for marking abnormal data sources in the graph construction module provided in this embodiment of the invention, as shown below. Figure 8 As shown, the map construction module 500 also includes: The deviation calculation submodule 5004 is used to compare the motion trajectory of each involved data source with the corresponding motion trajectories of other involved data sources to obtain deviation data.

[0210] Using the spatiotemporal scope of the accident as a boundary, the self-reported movement trajectory of the vehicle involved and the observed movement trajectory of the roadside unit are obtained. Further trajectory comparison is then performed based on these results. For each vehicle involved in the incident, its self-reported trajectory is compared hourly with the observed trajectory of each RSU covering the vehicle to generate one or more "vehicle-RSU" deviation sequences; its self-reported trajectory is also compared hourly with the self-reported trajectories of other vehicles involved in the incident to generate "vehicle-vehicle" deviation sequences.

[0211] For each roadside unit, its observed motion trajectory for a certain vehicle is compared with the self-reported motion trajectory of that vehicle to generate an "RSU-vehicle" deviation sequence; its observed trajectory for the same vehicle is compared with the observed trajectories of other RSUs (if any) for that vehicle to generate an "RSU-RSU" deviation sequence.

[0212] The deviation sequences generated by the above comparisons collectively constitute the deviation data for each data source involved. The instantaneous deviation value in each deviation sequence reflects the degree of consistency of that data source at different time points and under different comparison benchmarks.

[0213] The abnormal data source marking submodule 5005 is used to compare the deviation data of each involved vehicle with a preset deviation threshold. When the deviation data exceeds the preset deviation threshold, the involved data source is marked as an abnormal data source.

[0214] For each type of deviation, a corresponding threshold is preset (e.g., a position deviation threshold of 5 meters, a speed deviation threshold of 10 km / h). For each data source involved (vehicle or roadside unit), anomaly determination is made by combining all its deviation sequences.

[0215] In one optional implementation, a single-dimensional anomaly determination is adopted. For any deviation sequence, if the instantaneous deviation value in the sequence exceeds a preset proportion (e.g., 10%) and exceeds a threshold, or if the statistical characteristics (mean, maximum value) of the sequence exceed the threshold, then the data source is determined to have an anomaly in the comparison dimension.

[0216] In another optional implementation, a multi-dimensional cross-judgment is adopted. If a data source is judged as abnormal in multiple independent comparison dimensions (e.g., comparison with multiple different RSUs, comparison with multiple other vehicles, comparison with physical constraints), then the data source is marked as an abnormal data source.

[0217] As an optional implementation method, Figure 9 This is a schematic diagram of the weight calculation module provided in an embodiment of the present invention, as shown below. Figure 9 As shown, the weight calculation module 600 includes: The first coefficient calculation submodule 6001 is used to determine the device reliability coefficient of each data source involved in the incident based on the device status data of each data source involved in the incident.

[0218] Assess the reliability of the hardware and sensors of the data source involved (vehicle or roadside unit) and quantify it as a device reliability coefficient. Device status data includes, but is not limited to: sensor calibration status, device fault code records, etc.

[0219] The device stores data in the database of the car manufacturer or RSU operator, and it is stored locally in an encrypted form. Data processing can be achieved through privacy-preserving computation.

[0220] According to preset rules, device status data is mapped to a device confidence coefficient between 0 and 1.

[0221] Mapping rule example: Calibration was effective and no faults were recorded: the equipment reliability coefficient is 1.0; Calibration was valid but fault records exist: the equipment reliability coefficient is 0.5; Calibration invalid and no fault record: Equipment reliability coefficient is 0.3; Invalid calibration and fault records: Equipment reliability coefficient is 0.

[0222] The second coefficient calculation submodule 6002 is used to determine the identity credibility coefficient of each data source involved in the incident based on the identity verification results of each data source involved.

[0223] The identity verification result includes at least two states: valid (VC signature correct, not expired, not cancelled) and invalid (VC expired, cancelled, signature mismatch, or identity credential missing). The verification state is mapped to a coefficient between 0 and 1 according to preset rules. For example, when the identity verification result is valid, the identity credibility coefficient = 1; when the identity verification result is invalid, the identity credibility coefficient = 0.

[0224] If the identity verification result contains intermediate states (such as about to expire or within the grace period), an intermediate coefficient value (such as 0.8) can be set accordingly, but at least the two basic states of valid and invalid should be distinguished.

[0225] The third coefficient calculation submodule 6003 is used to determine the data integrity coefficient of each data source involved in the incident based on the integrity verification results of each data source involved.

[0226] The integrity verification result includes at least two states: pass (the on-chain notarized hash matches the actual calculated hash, and the data has not been tampered with) and fail (the hash is inconsistent or the data is missing). The verification state is mapped to a coefficient between 0 and 1 according to preset rules. For example, when the integrity verification result is pass, the data integrity coefficient = 1.0; when the integrity verification result is fail, the data integrity coefficient = 0.

[0227] If there are intermediate situations during the verification process, such as some data fragments being missing but the whole data still being partially usable (e.g., the missing percentage is lower than the preset threshold), an intermediate coefficient (e.g., 0.5) can be set, but at least the two basic states of passing and failing should be distinguished.

[0228] The fourth coefficient calculation submodule 6004 is used to calculate the consistency coefficient of each data source involved based on the deviation data of each data source involved.

[0229] For each data source involved, a consistency coefficient between 0 and 1 is calculated based on its deviation data. The smaller the deviation, the higher the consistency coefficient; the larger the deviation, the lower the consistency coefficient.

[0230] The specific mapping method can be any of the following: calculate the mean or maximum value of the deviation sequence, compare it with the preset deviation threshold, and map it to a coefficient according to a piecewise linear function or an exponential decay function. For example, the coefficient is 1 when the deviation mean is 0, the coefficient is 0.5 when the deviation mean reaches the threshold, and the coefficient approaches 0 after exceeding the threshold; count the proportion of points in the deviation sequence that exceed the preset threshold, and the consistency coefficient = 1 - the proportion of exceeding the limit (or use a smoother function).

[0231] For multiple deviation items in the deviation data from the same data source, a weighted sum can be performed to obtain a final consistency coefficient.

[0232] The weight fusion submodule 6005 is used to calculate the trust weight of the data source involved in the incident based on the device trust coefficient, identity trust coefficient, data integrity coefficient, and consistency coefficient of the same data source involved in the incident.

[0233] The four coefficients are combined into a comprehensive confidence weight. One of the following three methods can be used: The product method involves multiplying the four coefficients. If any coefficient is 0, the weight is 0; if all coefficients are 1, the weight is 1. This method is sensitive to low scores; the weight is only high when all dimensions are good.

[0234] The weighted summation method involves assigning a preset weight to each coefficient and then calculating the weighted sum. Each coefficient can be compensated independently, making it suitable for scenarios where the importance of different dimensions is clearly distinguished.

[0235] The model-based approach uses four coefficients as input feature vectors, which are then fed into a pre-trained machine learning model (such as logistic regression or a small neural network). The model outputs confidence weights. The model can be derived by learning the non-linear relationship between each coefficient and the true confidence level of the data source from historical data.

[0236] As an optional implementation method, Figure 10 This is a structural schematic diagram of the responsibility allocation module provided in an embodiment of the present invention, as shown below. Figure 10 As shown, the responsibility allocation module 700 includes: The feature pair generation submodule 7001 is used to combine the encrypted incident features of each involved data source with the corresponding trusted weights into input feature pairs.

[0237] For each data source involved, its encrypted incident feature vector is combined with trusted weights. The combination can be done by either adding the weights as an additional dimension to the feature vector, i.e., constructing a concatenated extended vector; or by storing the weights separately and establishing a mapping relationship with the feature vector to form a feature pair.

[0238] The input vector generation submodule 7002 is used to arrange the input feature pairs of all involved data sources in a preset order to construct the model input vector.

[0239] A fixed sorting method is pre-agreed upon, such as sorting by the type of data source involved (vehicles first, roadside units second) or by the identifier of the data source in ascending or descending order. All participants use the same sorting rule before model computation to ensure that the dimensions of the input vectors are consistent.

[0240] For each feature pair, all input feature pairs are concatenated in a preset order to form a complete model input vector.

[0241] The completed model input vector exists in encrypted form and is input into the pre-defined judgment model for forward computation. The entire permutation and construction process is completed within a privacy-preserving computation environment.

[0242] The responsibility ratio determination submodule 7003 is used to input the model input vector into the preset responsibility judgment model to obtain each responsible party and the corresponding responsibility ratio.

[0243] A liability determination model is a pre-trained, computable model that accepts a fixed-dimensional input vector and outputs a probability distribution or proportion of each responsible party. Examples include logistic regression, a softmax classifier, or a small neural network, with model parameters trained using historical accident data.

[0244] The model outputs the liability ratio of each party, for example: car owner 52%, car manufacturer 30%, third party 10%, and road environment 8%. The output can be plaintext (viewable after being shared by all parties) or encryptedtext (viewable after being decrypted by other participants).

[0245] The above technical solution has the following beneficial effects: By hashing and storing multi-source data on the blockchain and retaining the original data locally, the privacy of all parties is protected under the premise of data immutability, thus solving the problems of centralized storage being easily tampered with and privacy leakage caused by plaintext sharing; by constructing a spatiotemporal consistency graph and calculating deviation data and abnormal data source markers, cross-verification of multi-vehicle and roadside data is realized, thereby eliminating deviations caused by single data source failures or forgery and improving the reliability of the basis for liability determination; by dynamically calculating the trust weight based on device status, identity verification, integrity verification, and deviation data, data sources of different quality have a differentiated impact on liability determination, thereby enhancing the robustness of the liability determination model to abnormal data; by inputting encrypted accident features under a secure multi-party computation framework and combining the trust weight with preset liability rules to calculate the liability ratio, all parties can complete collaborative determination without disclosing the original data, thus balancing data privacy and the accuracy of calculation results; by generating a liability determination report and storing it on the blockchain based on the liability ratio, trust weight, spatiotemporal consistency graph, and abnormal data source markers, the entire determination process is traceable and non-repudiable, thus forming a complete and reliable automated liability determination closed loop.

[0246] The above-described specific embodiments of the invention further illustrate the purpose, technical solution, and beneficial effects of the invention. It should be understood that the above content is only for specific embodiments of the invention and is not intended to limit the scope of protection of the invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the invention should be included within the scope of protection of the invention.

Claims

1. A method for determining traffic liability in multi-party collaborative autonomous driving, characterized in that, include: Raw data from various data sources are collected in real time; among them, the raw data corresponding to the vehicle data source is vehicle operation data, and the raw data corresponding to the roadside unit data source is roadside environmental data. The original data from each data source is hash digested to obtain the corresponding comparison hash digest, which is then stored on the blockchain for evidence. When a traffic accident occurs, the relevant raw data of each data source involved in the accident within the time period of the accident is obtained, and the actual hash digest of each relevant raw data is calculated. The integrity is verified by comparing the actual hash digest with the corresponding comparison hash digest to obtain the integrity verification result. Identity verification is performed based on the identity credentials of each data source involved, and the identity verification results are obtained. Based on the relevant raw data from each data source involved, the characteristics of the encrypted incident are obtained. A spatiotemporal consistency map is constructed based on all the characteristics of the encrypted incident. Based on the spatiotemporal consistency map, the deviation data between each data source involved and the abnormal data source markers are calculated. Based on the device status data of each data source involved, the identity verification results, the integrity verification results, and the deviation data, the trust weight of each data source involved is calculated. Based on the characteristics of encrypted incidents, credibility weights, and pre-set liability assessment models of each data source involved, the liability ratios of each responsible party and their respective liabilities are obtained. Based on the aforementioned responsibility ratio, credibility weight, spatiotemporal consistency graph, and abnormal data source markers, a responsibility determination report is generated and stored on the blockchain.

2. The method for determining traffic liability in multi-party collaborative autonomous driving according to claim 1, characterized in that, The construction of a spatiotemporal consistency map based on all ciphertext incident characteristics includes: Extract the timestamps and their corresponding spatial coordinates from the accident features of each encrypted message, and construct a unified spatiotemporal coordinate system using the timestamps as a time reference and the spatial coordinates as a spatial reference. In the unified spatiotemporal coordinate system, nodes of the involved vehicles, roadside units, traffic signals, road environment, and accidents are added according to the characteristics of each encrypted accident. In the unified spatiotemporal coordinate system, vehicle trajectory edges, relative position edges, observation coverage edges, traffic light constraint edges, road environment influence edges, and collision association edges are constructed between nodes to obtain the spatiotemporal consistency map. Among them, the vehicle trajectory edge is the edge between the involved vehicle nodes corresponding to the same vehicle at different timestamps, the relative position edge is the edge between the involved vehicle nodes corresponding to different vehicles, the observation coverage edge is the edge between the roadside unit node and the relevant involved vehicle, the traffic light constraint edge is the edge between the traffic signal node and the relevant involved vehicle, the road environment influence edge is the edge between the road environment node and the relevant involved vehicle node, and the collision association edge is the edge between the accident node and the relevant involved vehicle.

3. The method for determining traffic liability in multi-party collaborative autonomous driving according to claim 2, characterized in that, The step of calculating the deviation data and abnormal data source markers between the involved data sources based on the spatiotemporal consistency map includes: For each data source involved, the deviation data is obtained by comparing the motion trajectory of that data source with the corresponding motion trajectories of other data sources involved. The deviation data of each vehicle involved is compared with a preset deviation threshold. When the deviation data exceeds the preset deviation threshold, the data source involved is marked as an abnormal data source.

4. The method for determining traffic liability in multi-party collaborative automated driving according to claim 1, characterized in that, The step of calculating the trust weight of each data source involved in the incident based on the device status data, the identity verification result, the integrity verification result, and the deviation data includes: Based on the device status data of each data source involved, determine the device reliability coefficient of each data source involved. Based on the identity verification results of each data source involved, the identity credibility coefficient of each data source involved is determined. Based on the integrity verification results of each data source involved, determine the data integrity coefficient for each data source involved. Based on the deviation data of each data source involved, calculate the consistency coefficient of each data source involved. The trust weight of the data source in question is calculated based on the device trust coefficient, identity trust coefficient, data integrity coefficient, and consistency coefficient of the same data source involved.

5. The method for determining traffic liability in multi-party collaborative automated driving according to claim 1, characterized in that, The process involves determining the responsible party and their respective liability ratios based on the encrypted incident characteristics, credibility weights, and a pre-defined liability assessment model for each data source involved. The encrypted incident features of each data source involved are combined with their corresponding trusted weights to form input feature pairs; Arrange the input feature pairs of all involved data sources in a preset order to construct the model input vector; The model input vector is input into a preset liability assessment model to obtain each responsible party and their corresponding liability ratio.

6. A multi-party collaborative autonomous driving traffic liability determination system, characterized in that, include: The data acquisition module is used to collect raw data from various data sources in real time; among them, the raw data corresponding to the vehicle data source is vehicle operation data, and the raw data corresponding to the roadside unit data source is roadside environmental data. The hash digest module is used to calculate hash digests of the raw data from each data source, obtain the corresponding comparison hash digests, and store them on the blockchain. The first verification module is used to obtain the relevant original data of each data source involved in the accident within the time period of the accident when a traffic accident occurs, calculate the actual hash digest of each relevant original data, and perform integrity verification based on the actual hash digest and the corresponding comparison hash digest to obtain the integrity verification result. The second verification module is used to verify the identity based on the identity credentials of each data source involved and obtain the identity verification result. The graph construction module is used to obtain encrypted incident characteristics based on the relevant raw data of each data source involved, construct a spatiotemporal consistency graph based on all encrypted incident characteristics, and calculate the deviation data and abnormal data source markers between each data source involved based on the spatiotemporal consistency graph. The weight calculation module is used to calculate the trust weight of each data source involved based on the device status data, the identity verification result, the integrity verification result, and the deviation data. The responsibility allocation module is used to obtain the responsibility ratio of each responsible party based on the encrypted accident characteristics, credibility weight, and preset responsibility judgment model of each data source involved. The report generation module is used to generate a responsibility determination report based on the responsibility ratio, credibility weight, spatiotemporal consistency map, and abnormal data source markers, and then store it on the blockchain for evidence.

7. The multi-party collaborative autonomous driving traffic liability determination system according to claim 6, characterized in that, The map construction module includes: The spatiotemporal coordinate system construction submodule is used to extract the timestamps and their corresponding spatial coordinates from the characteristics of each encrypted incident, and to construct a unified spatiotemporal coordinate system using the timestamps as the time reference and the spatial coordinates as the spatial reference. The node adding submodule is used to add involved vehicle nodes, roadside unit nodes, traffic signal nodes, road environment nodes, and accident nodes in the unified spatiotemporal coordinate system according to the characteristics of each encrypted accident. A submodule for adding nodes is used to construct vehicle trajectory edges, relative position edges, observation coverage edges, traffic light constraint edges, road environment influence edges, and collision association edges between nodes in the unified spatiotemporal coordinate system, thereby obtaining the spatiotemporal consistency map. Specifically, the vehicle trajectory edges are edges between involved vehicle nodes corresponding to the same vehicle at different timestamps; the relative position edges are edges between involved vehicle nodes corresponding to different vehicles; the observation coverage edges are edges between roadside unit nodes and related involved vehicles; the traffic light constraint edges are edges between traffic signal nodes and related involved vehicles; the road environment influence edges are edges between road environment nodes and related involved vehicle nodes; and the collision association edges are edges between accident nodes and related involved vehicles.

8. The multi-party collaborative autonomous driving traffic liability determination system according to claim 7, characterized in that, The map construction module also includes: The deviation calculation submodule is used to compare the motion trajectory of each data source with the corresponding motion trajectories of other data sources to obtain deviation data. The abnormal data source marking submodule is used to compare the deviation data of each involved vehicle with a preset deviation threshold. When the deviation data exceeds the preset deviation threshold, the involved data source is marked as an abnormal data source.

9. The multi-party collaborative autonomous driving traffic liability determination system according to claim 6, characterized in that, The weight calculation module includes: The first coefficient calculation submodule is used to determine the device reliability coefficient of each data source involved in the incident based on the device status data of each data source involved in the incident. The second coefficient calculation submodule is used to determine the identity credibility coefficient of each data source involved in the incident based on the identity verification results of each data source involved in the incident. The third coefficient calculation submodule is used to determine the data integrity coefficient of each data source involved in the incident based on the integrity verification results of each data source involved in the incident. The fourth coefficient calculation submodule is used to calculate the consistency coefficient of each data source involved based on the deviation data of each data source involved. The weight fusion submodule is used to calculate the trust weight of the data source involved in the incident based on the device trust coefficient, identity trust coefficient, data integrity coefficient, and consistency coefficient of the same data source involved in the incident.

10. The multi-party collaborative autonomous driving traffic liability determination system according to claim 6, characterized in that, The responsibility allocation module includes: The feature pair generation submodule is used to combine the encrypted incident features of each involved data source with the corresponding trusted weights into input feature pairs; The input vector generation submodule is used to arrange the input feature pairs of all involved data sources in a preset order to construct the model input vector; The responsibility ratio determination submodule is used to input the model input vector into a preset responsibility judgment model to obtain each responsible party and its corresponding responsibility ratio.

Images