A cloud data monitoring method based on vehicle networking

Abstract

The application discloses a cloud data monitoring method based on Internet of Vehicles, and relates to the technical field of Internet of Vehicles data monitoring, and comprises the following steps: S1, collecting vehicle operation data on a vehicle-mounted terminal of a vehicle to be monitored, and performing structured processing to generate a plurality of operation data packets; S2, generating a to-be-attested data tuple for each operation data packet; S3, generating an attestation voucher for the to-be-attested data tuple by using a lightweight consensus mechanism; S4, generating a data index record according to the attestation voucher of the to-be-attested data tuple and the storage address of the operation data packet in a distributed network; and S5, writing the data index record into a block chain. The application associates multi-dimensional information such as the attestation voucher and the data storage address, forms a complete trust chain from attestation to index, ensures that the index is tamper-proof, and is compatible with different vehicle models and data types.

Description

Technical Field

[0001] This invention relates to the field of vehicle network data monitoring technology, and specifically to a cloud-based data monitoring method based on vehicle network. Background Technology

[0002] With the booming development of the intelligent connected vehicle industry, vehicles have evolved from closed mechanical systems into mobile intelligent terminals integrating a large number of electronic control units, sensors, and communication modules. In the vehicle-to-everything (V2X) environment, vehicles not only achieve internal data interaction through the controller area network bus, but also share data in real time with surrounding vehicles, roadside units, and cloud platforms using V2X communication technology. A vehicle with advanced autonomous driving capabilities can generate more than 4TB of data per day, covering multi-dimensional information such as location trajectory, driving behavior, and environmental perception.

[0003] These massive amounts of vehicle operation data have multiple important values: in the field of traffic safety, key data before and after an accident can serve as the core basis for determining liability; in insurance claims scenarios, driving behavior data supports usage-based insurance (UBI) innovation; in the realm of intelligent traffic management, real-time traffic flow data provides a decision-making basis for traffic light optimization and congestion mitigation; and in terms of judicial evidence collection, vehicle electronic data has become the third largest evidence collection medium after computers and mobile phones, playing an increasingly important role in traffic accident investigations and case solving.

[0004] However, current vehicle operation data in the Internet of Vehicles (IoV) is collected and uploaded by onboard terminals, but the data recipient cannot directly verify whether this data has been tampered with or forged. Typical cases have emerged in practice: in a brand-related rights protection case, users questioned whether the data provided by the automaker had been processed, and the completeness of the provided data differed significantly, raising widespread public concerns about the authenticity of the data. Furthermore, in existing IoV data supervision technology solutions, data is controlled by a single entity (automaker or terminal), lacking a multi-party endorsement mechanism for confirming ownership. Data recipients can only passively trust the data provider and cannot independently verify the data. Summary of the Invention

[0005] To address the above problems, this invention proposes a cloud-based data monitoring method based on the Internet of Vehicles.

[0006] The technical solution of this invention is: a cloud-based data monitoring method based on vehicle networking, comprising the following steps:

[0007] S1. Collect vehicle operation data at the vehicle terminal of the vehicle to be monitored, perform structured processing, and generate several operation data packets.

[0008] S2. Generate a data tuple to be stored for each running data packet;

[0009] S3. Use a lightweight consensus mechanism to generate proof of existence for the data tuples to be proven.

[0010] S4. Generate a data index record based on the evidence of the data tuple to be stored and the storage address of the running data packet in the distributed network.

[0011] S5. Write the data index record to the blockchain.

[0012] Furthermore, in S2, the data tuple to be stored is specifically as follows: ;in, This represents the hash value of the running data packet. Indicates the timestamp of the running data packet. This represents the decentralized identity identifier of the vehicle to be monitored. Indicates the data type of the running data packet.

[0013] Data types can distinguish different data categories, such as driving data, battery data, and fault data.

[0014] Furthermore, S3 includes the following sub-steps:

[0015] S31. Construct a reputation model and calculate the reputation value of each edge node;

[0016] S32. Select the top k edge nodes by reputation value as temporary consensus nodes, and select the edge node with the highest reputation value as the leader node, where k represents the preset number of nodes.

[0017] S33. Use temporary consensus nodes to obtain neighboring vehicles that are in the same time window and the same preset area as the vehicle to be monitored;

[0018] S34. Pack the data tuples and data digests of the vehicles to be monitored and their neighbors into candidate blocks and distribute them to all temporary consensus nodes.

[0019] S35. Determine the initial and secondary voting results of each temporary consensus node;

[0020] S36. Using the temporary consensus node where both the initial and secondary voting results are successful, generate a partial signature and transmit it to the leader node;

[0021] S37. Use the threshold signature method of the leader node to determine the evidence storage certificate.

[0022] The beneficial effects of the above-mentioned further scheme are as follows: In this invention, within the current consensus period, all online edge nodes calculate their reputation value based on their historical performance (such as online duration, historical voting accuracy, and current load), and elect the top few nodes with the highest reputation to form a temporary consensus committee. The leader node (the one with the highest reputation) in the committee collects multiple data tuples to be stored within a time window. For each tuple, the leader node obtains the data digest (such as the mean and standard deviation of speed) of the vehicle from its local cache or distributed ledger based on its DID. Based on the geographical location information associated with the DID, it determines a list of other vehicles in the same time period and area as the vehicle, and obtains the data of these vehicles in the current window. The leader node packages all data tuples to be stored, historical digests, and neighbor vehicle data into a candidate block and distributes it to all committee members. After receiving the block, each node independently performs a verification process for each data tuple to be stored, determines the voting result, and generates a partial signature. The leader node collects partial signatures from the remaining nodes. When the number of collected partial signatures reaches a threshold, a threshold signature aggregation algorithm is used to generate a complete storage certificate.

[0023] If the threshold is not reached, a retransmission request is sent to all committee nodes, requesting nodes that did not send partial signatures to retransmit. If the number of partial signatures received after retransmission is still insufficient, the consensus is declared a failure. All committee nodes monitor the frequency of consensus failures, and when the number of consecutive failures reaches a threshold (e.g., 3 times), they proactively initiate a committee re-election.

[0024] The data tuples to be stored are broadcast to the consensus network composed of roadside units or nearby edge computing nodes.

[0025] Furthermore, in S31, the reputation model The expression is:

[0026] ;

[0027] in, Represents a node Online rate, Represents a node Historical voting accuracy Represents a node The current load, The weight representing the online rate, The weights representing the historical accuracy of voting. Indicates the weight of the current load;

[0028] In S34, the data summary includes numerical indicators for the current time period and numerical indicators for historical time periods in the vehicle operation data.

[0029] The beneficial effects of the above-mentioned further solutions are: In this invention, the reputation model comprehensively considers factors such as the online duration of nodes, the accuracy of historical consensus participation, and the idle rate of computing resources. Nodes must be online to participate in consensus. Even with high reputation, a node is useless if it is frequently offline. A node's past voting record reflects its honesty. Even if a node is online and honest, a heavy load (such as processing a large number of tasks) can cause slow responses, impacting consensus efficiency. These three coefficients control the relative importance of the three factors.

[0030] Furthermore, S35 includes the following sub-steps:

[0031] S351. Take the average of the data summary of the vehicle to be monitored for the current time period as the aggregation value;

[0032] S352. Use a sliding window to iterate through the data summary of the historical time period, and take the mean of the linear fitting values ​​of all windows as the historical trend value.

[0033] S353. Determine the deviation based on the difference between the aggregated value and the historical trend value;

[0034] S354. Determine the initial voting results of the temporary consensus nodes based on the deviation degree, and proceed to S355;

[0035] S355. Take the average of the data summaries of each neighboring vehicle for the current time period as the reference aggregate value, and calculate the difference between the aggregate value and the average of all reference aggregate values ​​as the lateral deviation of the vehicle to be monitored.

[0036] S356. Determine the secondary voting results of the temporary consensus node based on the lateral deviation.

[0037] The beneficial effects of the above-mentioned further solutions are as follows: In this invention, each node maintains a cache of historical vehicle data. However, due to network latency, node failures, and other reasons, it is difficult for nodes to synchronize a completely consistent data view. For example, if node A has a complete set of the most recent L historical windows, while node B only has L-1, their calculated trend sequences will differ, leading to different normalization biases, and one might pass while the other fails. Furthermore, the definition of neighboring vehicles is usually based on geographical location. Since each node may use different location information sources or different caching strategies, their determined neighbor lists may differ slightly, also leading to different voting results.

[0038] Furthermore, in S353, the deviation... The expression is:

[0039] ;

[0040] in, Indicates the current time period The aggregate value, Indicates historical time period Historical trend values, Indicates the current time period Standard deviation of internal data summary This indicates a minimum value to prevent the denominator from being zero;

[0041] In S354, if the deviation is less than the set threshold, the initial voting result of the temporary consensus node is successful; otherwise, it is rejected.

[0042] In S356, if the lateral deviation is less than the set threshold, the secondary voting result of the temporary consensus node is successful; otherwise, it is rejected.

[0043] Furthermore, in S36, some signatures The expression is:

[0044] ;

[0045] in, This represents the private key fragment of a temporary consensus node whose initial and secondary voting results are both successful. Indicates a candidate block. This represents a hash operation. This represents the signature generation function.

[0046] The beneficial effect of the above-described further scheme is that, in this invention, during system initialization, all nodes jointly run a protocol to generate a common aggregate public key, while each node obtains a fragment of a private key. No single node knows the complete private key.

[0047] Furthermore, in S4, the data index records use JSON structured text.

[0048] The beneficial effects of this invention are as follows: This invention combines the hash value of the running data packet and various feature parameters into a data tuple to be stored, and uses a lightweight consensus mechanism to generate a storage certificate. That is, through a reputation model, several of the most reliable nodes are dynamically elected from the edge nodes of the entire network to form a temporary committee, and threshold signatures are used to replace the traditional multi-round broadcast voting to aggregate the final certificate. The storage certificate and multi-dimensional information such as the data storage address are linked together to form a complete trust chain from storage to indexing, ensuring that the index is tamper-proof and compatible with different vehicle models and data types. Attached Figure Description

[0049] Figure 1 This is a flowchart of a cloud-based data monitoring method based on vehicle-to-everything (V2X) connectivity. Detailed Implementation

[0050] The embodiments of the present invention will be further described below with reference to the accompanying drawings.

[0051] like Figure 1 As shown, the present invention provides a cloud-based data monitoring method based on the Internet of Vehicles, comprising the following steps:

[0052] S1. Collect vehicle operation data at the vehicle terminal of the vehicle to be monitored, perform structured processing, and generate several operation data packets.

[0053] S2. Generate a data tuple to be stored for each running data packet;

[0054] S3. Use a lightweight consensus mechanism to generate proof of existence for the data tuples to be proven.

[0055] S4. Generate a data index record based on the evidence of the data tuple to be stored and the storage address of the running data packet in the distributed network.

[0056] S5. Write the data index record to the blockchain.

[0057] In this embodiment of the invention, in S2, the data tuple to be stored is specifically: ;in, This represents the hash value of the running data packet. Indicates the timestamp of the running data packet. This represents the decentralized identity identifier of the vehicle to be monitored. Indicates the data type of the running data packet.

[0058] Vehicle operation data can include data collected by the onboard terminal, such as the vehicle's speed or battery temperature at various times, depending on the actual situation. Data types can be distinguished into different categories, such as driving data, battery data, and other data.

[0059] In this embodiment of the invention, S3 includes the following sub-steps:

[0060] S31. Construct a reputation model and calculate the reputation value of each edge node;

[0061] S32. Select the top k edge nodes by reputation value as temporary consensus nodes, and select the edge node with the highest reputation value as the leader node, where k represents the preset number of nodes.

[0062] S33. Use temporary consensus nodes to obtain neighboring vehicles that are in the same time window and the same preset area as the vehicle to be monitored;

[0063] S34. Pack the data tuples and data digests of the vehicles to be monitored and their neighbors into candidate blocks and distribute them to all temporary consensus nodes.

[0064] S35. Determine the initial and secondary voting results of each temporary consensus node;

[0065] S36. Using the temporary consensus node where both the initial and secondary voting results are successful, generate a partial signature and transmit it to the leader node;

[0066] S37. Use the threshold signature method of the leader node to determine the evidence storage certificate.

[0067] In this invention, within the current consensus period, all online edge nodes calculate their reputation scores based on their historical performance (e.g., online duration, historical voting accuracy, current load), and elect the top few nodes with the highest reputation to form a temporary consensus committee. The leader node (the one with the highest reputation) in the committee collects multiple data tuples to be stored within a time window. For each tuple, the leader node retrieves a data digest (e.g., mean and standard deviation of speed) for that vehicle from its local cache or distributed ledger based on its DID. Based on the geographical location information associated with the DID, it determines a list of other vehicles in the same time period and area as that vehicle, and retrieves their data for the current window. The leader node packages all data tuples to be stored, historical digests, and neighbor vehicle data into a candidate block and distributes it to all committee members. Upon receiving the block, each node independently performs a verification process for each data tuple to be stored, determines the voting result, and generates a partial signature. The leader node collects partial signatures from the remaining nodes. When the number of collected partial signatures reaches a threshold, a threshold signature aggregation algorithm is used to generate a complete storage certificate.

[0068] If the threshold is not reached, a retransmission request is sent to all committee nodes, requesting nodes that did not send partial signatures to retransmit. If the number of partial signatures received after retransmission is still insufficient, the consensus is declared a failure. All committee nodes monitor the frequency of consensus failures, and when the number of consecutive failures reaches a threshold (e.g., 3 times), they proactively initiate a committee re-election.

[0069] The data tuples to be stored are broadcast to the consensus network composed of roadside units or nearby edge computing nodes.

[0070] In this embodiment of the invention, in S31, the reputation model The expression is:

[0071] ;

[0072] in, Represents a node Online rate, Represents a node Historical voting accuracy Represents a node The current load, The weight representing the online rate, The weights representing the historical accuracy of voting. Indicates the weight of the current load;

[0073] In S34, the data summary includes numerical indicators for the current time period and numerical indicators for historical time periods in the vehicle operation data.

[0074] In this invention, the reputation model comprehensively considers factors such as the online duration of nodes, the accuracy of historical consensus participation, and the idle rate of computing resources. Nodes must be online to participate in consensus. Even with high reputation, a node is useless if it is frequently offline. A node's past voting record reflects its honesty. Even if a node is online and honest, a heavy load (such as processing a large number of tasks) can cause slow responses, impacting consensus efficiency. These three coefficients control the relative importance of the three factors.

[0075] In this embodiment of the invention, S35 includes the following sub-steps:

[0076] S351. Take the average of the data summary of the vehicle to be monitored for the current time period as the aggregation value;

[0077] S352. Use a sliding window to iterate through the data summary of the historical time period, and take the mean of the linear fitting values ​​of all windows as the historical trend value.

[0078] S353. Determine the deviation based on the difference between the aggregated value and the historical trend value;

[0079] S354. Determine the initial voting results of the temporary consensus nodes based on the deviation degree, and proceed to S355;

[0080] S355. Take the average of the data summaries of each neighboring vehicle for the current time period as the reference aggregate value, and calculate the difference between the aggregate value and the average of all reference aggregate values ​​as the lateral deviation of the vehicle to be monitored.

[0081] S356. Determine the secondary voting results of the temporary consensus node based on the lateral deviation.

[0082] In this invention, each node maintains a cache of historical vehicle data. However, due to network latency, node failures, and other factors, it is difficult for nodes to synchronize a completely consistent data view. For example, node A may have a complete set of the most recent L historical windows, while node B may only have L-1. Consequently, their calculated trend sequences will differ, leading to different normalization biases, and one might pass while the other fails. Furthermore, the definition of neighboring vehicles is typically based on geographical location. Since nodes may use different location information sources or different caching strategies, their determined neighbor lists may vary slightly, also resulting in different voting results.

[0083] In this embodiment of the invention, in S353, the deviation degree The expression is:

[0084] ;

[0085] in, Indicates the current time period The aggregate value, Indicates historical time period Historical trend values, Indicates the current time period Standard deviation of internal data summary This indicates a minimum value to prevent the denominator from being zero;

[0086] In S354, if the deviation is less than the set threshold, the initial voting result of the temporary consensus node is successful; otherwise, it is rejected.

[0087] In S356, if the lateral deviation is less than the set threshold, the secondary voting result of the temporary consensus node is successful; otherwise, it is rejected.

[0088] In this embodiment of the invention, in S36, a partial signature... The expression is:

[0089] ;

[0090] in, This represents the private key fragment of a temporary consensus node whose initial and secondary voting results are both successful. Indicates a candidate block. This represents a hash operation. This represents the signature generation function.

[0091] In this invention, during system initialization, all nodes jointly run a protocol to generate a common aggregate public key, while each node receives a fragment of a private key. No single node knows the complete private key.

[0092] In this embodiment of the invention, in S4, the data index record uses JSON structured text.

[0093] Those skilled in the art will recognize that the embodiments described herein are intended to help the reader understand the principles of the invention, and should be understood that the scope of protection of the invention is not limited to such specific statements and embodiments. Those skilled in the art can make various other specific modifications and combinations based on the technical teachings disclosed in this invention without departing from the spirit of the invention, and these modifications and combinations are still within the scope of protection of this invention.

Claims

1. A cloud-based data monitoring method based on the Internet of Vehicles, characterized in that, Includes the following steps: S1. Collect vehicle operation data at the vehicle terminal of the vehicle to be monitored, perform structured processing, and generate several operation data packets. S2. Generate a data tuple to be stored for each running data packet; S3. Use a lightweight consensus mechanism to generate proof of existence for the data tuples to be proven. S4. Generate a data index record based on the evidence of the data tuple to be stored and the storage address of the running data packet in the distributed network. S5. Write the data index record to the blockchain; S3 includes the following sub-steps: S31. Construct a reputation model and calculate the reputation value of each edge node; S32. Select the top k edge nodes by reputation value as temporary consensus nodes, and select the edge node with the highest reputation value as the leader node, where k represents the preset number of nodes. S33. Use temporary consensus nodes to obtain neighboring vehicles that are in the same time window and the same preset area as the vehicle to be monitored; S34. Pack the data tuples and data digests of the vehicles to be monitored and their neighbors into candidate blocks and distribute them to all temporary consensus nodes. S35. Determine the initial and secondary voting results of each temporary consensus node; S36. Using the temporary consensus node where both the initial and secondary voting results are successful, generate a partial signature and transmit it to the leader node; S37. Use the threshold signature method of the leader node to determine the evidence storage certificate; S35 includes the following sub-steps: S351. Take the average of the data summary of the vehicle to be monitored for the current time period as the aggregation value; S352. Use a sliding window to iterate through the data summary of the historical time period, and take the mean of the linear fitting values ​​of all windows as the historical trend value. S353. Determine the deviation based on the difference between the aggregated value and the historical trend value; S354. Determine the initial voting results of the temporary consensus nodes based on the deviation degree, and proceed to S355; S355. Take the average of the data summaries of each neighboring vehicle for the current time period as the reference aggregate value, and calculate the difference between the aggregate value and the average of all reference aggregate values ​​as the lateral deviation of the vehicle to be monitored. S356. Determine the secondary voting results of the temporary consensus node based on the lateral deviation.

2. The cloud-based data monitoring method based on the Internet of Vehicles as described in claim 1, characterized in that, In S1, the vehicle operation data includes several parameters of the vehicle's operating status; In S2, the data tuple to be stored is specifically: ;in, This represents the hash value of the running data packet. Indicates the timestamp of the running data packet. This represents the decentralized identity identifier of the vehicle to be monitored. Indicates the data type of the running data packet.

3. The cloud-based data monitoring method based on the Internet of Vehicles as described in claim 1, characterized in that, In S31, the reputation model The expression is: ； in, Represents a node Online rate, Represents a node Historical voting accuracy Represents a node The current load, The weight representing the online rate, The weights representing the historical accuracy of voting. Indicates the weight of the current load; In step S34, the data summary includes numerical indicators for the current time period and numerical indicators for historical time periods in the vehicle operation data.

4. The cloud-based data monitoring method based on the Internet of Vehicles as described in claim 1, characterized in that, In S353, the deviation The expression is: ； in, Indicates the current time period The aggregate value, Indicates historical time period Historical trend values, Indicates the current time period Standard deviation of internal data summary This indicates a minimum value to prevent the denominator from being zero; In step S354, if the deviation is less than the set threshold, the initial voting result of the temporary consensus node is successful; otherwise, it is rejected. In step S356, if the lateral deviation is less than a set threshold, the secondary voting result of the temporary consensus node is successful; otherwise, it is rejected.

5. The cloud-based data monitoring method based on the Internet of Vehicles as described in claim 1, characterized in that, In S36, partial signature The expression is: ； in, This represents the private key fragment of a temporary consensus node whose initial and secondary voting results are both successful. Indicates a candidate block. This represents a hash operation. This represents the signature generation function.

6. The cloud-based data monitoring method based on vehicle networking according to claim 1, characterized in that, In S4, the data index records use JSON structured text.

Images