Internet of vehicles data processing method and vehicle end control equipment

Abstract

The invention relates to an Internet of Vehicles data processing method and vehicle end control equipment. The method comprises the steps of obtaining Internet of Vehicles data of a vehicle, evaluating the value level of the Internet of Vehicles data and generating a data abstract of the Internet of Vehicles data, determining the data uploading priority of the data abstract according to the data abstract, the value level and the operation state data, and uploading the data uploading priority of the data abstract to the vehicle according to the data uploading priority. And determining a data uploading strategy based on the network state data, the system resource data and the data uploading priority, and uploading the data abstract to a server based on the data uploading strategy. With the adoption of the method, the data validity, the transmission timeliness, the system stability and the data security can be considered under the condition of limited vehicle end resources, and the vehicle networking data uploading efficiency is remarkably improved.

Description

Technical Field

[0001] This application relates to the field of vehicle networking technology, and in particular to a vehicle networking data processing method and vehicle-side control device. Background Technology

[0002] With the rapid development of intelligent vehicles and vehicle networking technology, the amount of data generated by vehicle terminals every day is growing exponentially, including multi-source heterogeneous data continuously generated by the vehicle during driving, including video images, radar point clouds, controller area network (CAN) bus signals, driver status information, and various active safety warning events.

[0003] Currently, technologies related to vehicle-to-everything (V2X) data uploading typically trigger data uploads through fixed time periods or data volume thresholds. However, these methods still suffer from low data upload efficiency. Summary of the Invention

[0004] Based on this, this application addresses the aforementioned technical problems by providing an efficient vehicle network data processing method and vehicle-side control device.

[0005] Firstly, this application provides a method for processing vehicle network data, the method comprising:

[0006] Acquire vehicle network data, which includes operating status data, network status data, and system resource data;

[0007] Assess the value level of connected vehicle data and generate a data summary of the connected vehicle data;

[0008] The data upload priority of the data summary is determined based on the data summary, value level, and operational status data;

[0009] The data upload strategy is determined based on network status data, system resource data, and data upload priority.

[0010] Data summaries are uploaded to the server based on the data upload strategy.

[0011] The aforementioned vehicle-to-everything (V2X) data processing method effectively eliminates redundant information and significantly reduces data transmission volume by assessing the value level of V2X data and generating concise data summaries. It combines value level with real-time operational status data to dynamically determine data upload priority, reducing the practice of blindly transmitting non-critical data when resources are scarce, thereby improving the overall system resource utilization efficiency. Furthermore, based on this data upload priority and the operational environment status, the data upload strategy is jointly decided, achieving adaptive matching between data upload behavior and current vehicle-side capabilities, ensuring the timely upload of critical data. Finally, by uploading lightweight data summaries instead of raw data according to the data upload strategy, not only are communication bandwidth and storage costs significantly saved, but the risk of leakage of sensitive raw information is also reduced. In summary, under limited vehicle-side resource conditions, the above solution balances data validity, transmission timeliness, system stability, and data security, significantly improving the overall efficiency of V2X data upload.

[0012] In an optional embodiment of the first aspect, assessing the value level of vehicle-to-everything (V2X) data and generating a data summary of the V2X data includes:

[0013] Visual and numerical semantic features are extracted from vehicle network data;

[0014] By fusing visual semantic features and numerical semantic features, a fused semantic feature is obtained;

[0015] Based on the fusion of semantic features, the value level of vehicle-to-everything (V2X) data is assessed.

[0016] Based on the value level, determine the fidelity level of the data summary, and generate a data summary of the vehicle network data based on the fidelity level.

[0017] In this embodiment, driving events are identified by fusing visual and non-visual semantic features, and the fidelity of the data summary is dynamically set according to its value level. This ensures that high-value event information is effectively preserved while achieving adaptive compression of data volume, thereby improving data processing efficiency and the semantic usability of the data summary.

[0018] In an optional embodiment of the first aspect, assessing the value level of vehicle-to-everything (V2X) data based on fused semantic features includes:

[0019] Extract driving events from the fused semantic features, and assign weighted scores to the driving events from multiple preset dimensions to determine the value score of the driving events. The dimensions include at least two of the following: safety dimension, timeliness dimension, business dimension, and scarcity dimension.

[0020] Based on value scoring, the value level of driving events is determined, and the value level of driving events is used as the value level of vehicle-to-everything (V2X) data.

[0021] In this embodiment, by weighting and scoring driving events from multiple dimensions such as safety, timeliness, business, and scarcity, and classifying them into value levels, the importance of data is quantitatively distinguished, providing a unified and scalable evaluation basis for subsequent summary generation, encryption strategy selection, and upload priority decision-making.

[0022] In an optional embodiment of the first aspect, before determining the data upload strategy based on network status data, system resource data, and data upload priority, the method further includes:

[0023] Determine the sensitivity level of the data summary;

[0024] The target encryption strategy is determined based on sensitivity level, value level, and operational status data;

[0025] The data digest is encrypted according to the target encryption strategy to obtain the encrypted data digest.

[0026] Data digests are uploaded to the server based on the data upload strategy, including:

[0027] The encrypted data digest is uploaded to the server based on the data upload strategy.

[0028] In this embodiment, a sensitivity level assessment and dynamic encryption mechanism are introduced before determining the data upload strategy, thereby improving the overall reliability of vehicle network data transmission.

[0029] In an optional embodiment of the first aspect, determining the target encryption strategy based on sensitivity level, value level, and operational status data includes:

[0030] The encryption strategy that matches the sensitivity level, value level, and operational status data is selected from the preset encryption strategy decision matrix, and the selected encryption strategy is used as the target encryption strategy.

[0031] The target encryption strategy includes encryption algorithms, key length, and key update methods. Different sensitivity levels and different value levels correspond to encryption algorithms of different strengths.

[0032] In this embodiment, by using a preset encryption strategy decision matrix, the sensitivity level, value level and operating status data are jointly mapped to the target encryption strategy, thereby achieving dynamic adaptation of encryption strength, key management method and actual vehicle resource status, and reasonably controlling computing and energy consumption while ensuring data security.

[0033] In an optional embodiment of the first aspect, the data digest is encrypted according to a target encryption strategy to obtain an encrypted data digest, including:

[0034] In the presence of a network connection, a session key is generated in collaboration with the server, and the data digest is encrypted using the session key;

[0035] In the event of network unavailability, the data digest is encrypted using a locally cached backup key.

[0036] In this embodiment, by cooperating with the server to generate a session key when the network is available and enabling a locally cached backup key when the network is unavailable, the data digest can be effectively encrypted according to the target encryption strategy under various communication conditions, thus maintaining the continuity and reliability of end-to-end secure transmission.

[0037] In an optional embodiment of the first aspect, the network status data includes network bandwidth and signal strength. Based on the network status data, system resource data, and data upload priority, a data upload strategy is determined, including:

[0038] The data upload strategy is determined based on at least one of network bandwidth, signal strength, system resource data, and data upload priority.

[0039] The data upload strategy includes any one of the following: upload immediately, cache and wait for subsequent uploads, batch merge upload, or discard.

[0040] In this embodiment, by combining network status, signal strength, system resource status and data upload priority, strategies such as immediate upload, caching, batch merging or discarding can be dynamically selected to ensure timely transmission of high-priority data while rationally allocating limited network and computing resources on the vehicle side.

[0041] In an optional embodiment of the first aspect, the method further includes:

[0042] Receive feedback information regarding the data summary returned by the server;

[0043] If the feedback information indicates that the data summary needs adjustment, adjust the way the data summary is generated.

[0044] In this embodiment, by receiving feedback information returned by the server and dynamically adjusting the data digest generation method and data upload strategy accordingly, the collaborative optimization of the terminal processing logic and cloud usage requirements is achieved, thereby improving the information effectiveness of the semantic digest and the resource adaptability of the upload behavior.

[0045] In an optional embodiment of the first aspect, acquiring vehicle network data from multiple data sources includes:

[0046] Obtain raw vehicle network data from multiple data sources;

[0047] The raw data of the vehicle network is preprocessed to obtain vehicle network data. The data preprocessing includes at least one of the following: noise reduction, format normalization and redundant data removal.

[0048] In this embodiment, by performing at least one of the following preprocessing steps on the original vehicle network data—denoising, format normalization, and redundancy removal—the quality and consistency of the input data are effectively improved while retaining key event information. This provides a reliable foundation for subsequent high-precision value assessment and efficient semantic summary generation, while also reducing the consumption of computing resources and storage bandwidth by invalid data.

[0049] Secondly, this application also provides a vehicle-side control device, including a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the steps of the vehicle network data processing method described above.

[0050] Regarding the beneficial effects of the technical solution in the second aspect above, refer to the beneficial effects of the corresponding technical solution in the first aspect; repeated points will not be listed here. Attached Figure Description

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

[0052] Figure 1 This is a schematic diagram of an optional application environment for a vehicle-to-everything (V2X) data processing method in one embodiment.

[0053] Figure 2 This is a schematic diagram of an optional process for a vehicle-to-everything (V2X) data processing method in one embodiment;

[0054] Figure 3 This is a schematic diagram of an optional flow of a vehicle-to-everything (V2X) data processing method in another embodiment;

[0055] Figure 4 This is a schematic diagram of an optional process for generating a data digest in one embodiment;

[0056] Figure 5 This is an optional flowchart illustrating the data digest generation step in another embodiment;

[0057] Figure 6 This is a schematic diagram of an optional detailed process of the vehicle-to-everything (V2X) data processing method in yet another embodiment;

[0058] Figure 7This is a schematic diagram of an optional data encryption step in one embodiment;

[0059] Figure 8 This is a schematic diagram of an optional detailed process of the vehicle network data processing method in another embodiment;

[0060] Figure 9 This is a schematic diagram of an optional structure of a vehicle-to-everything (V2X) data processing device in one embodiment;

[0061] Figure 10 This is a schematic diagram of an optional structure of the vehicle-to-everything (V2X) data processing device in another embodiment;

[0062] Figure 11 This is a schematic diagram of an optional internal structure of a computer device in one embodiment. Detailed Implementation

[0063] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of this application.

[0064] The terms "first," "second," etc., used in this application may be used to describe various elements, but these elements are not limited by these terms. These terms are used only to distinguish the first element from the second element. The terms "comprising" and "having," and any variations thereof, used in this application, are intended to cover non-exclusive inclusion. The term "multiple" used in this application refers to two or more. The term "and / or" used in this application refers to one of the embodiments, or any combination of multiple embodiments.

[0065] The vehicle network data processing method provided in this application embodiment can be applied to, for example... Figure 1 In the application environment shown, the vehicle-mounted control device 102 communicates with the server 104 via a network. The data storage system can store the data that the server 104 needs to process. The data storage system can be integrated onto the server 104, or it can be located in the cloud or on another network server.

[0066] Specifically, the vehicle-side control device 102 can collect vehicle network data from multiple sources such as cameras, radar, and CAN bus, as well as operating status data including current network signal strength, battery level, and processor load. Then, it can evaluate the value level of the vehicle network data and generate a data summary of the vehicle network data. Based on the data summary, value level, and operating status data, it can determine the data upload priority of the data summary. Next, based on network status data, system resource data, and data upload priority, it can determine the data upload strategy. Finally, based on the data upload strategy, it can upload the data summary to the server.

[0067] The vehicle-side control device 102 can be, but is not limited to, various vehicle-to-everything (V2X) terminals, autonomous driving domain controllers, etc. The server 104 can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services.

[0068] In one exemplary embodiment, such as Figure 2 As shown, a vehicle-to-everything (V2X) data processing method is provided, which can be applied to... Figure 1 The following description uses the vehicle-side control device 102 (hereinafter referred to as the device) as an example, including steps 100 to 500. Wherein:

[0069] Step 100: Obtain vehicle network data, which includes operating status data, network status data, and system resource data.

[0070] Vehicle-to-everything (V2X) data refers to various types of information related to vehicles, roads, and the environment collected, transmitted, and processed in V2X systems through technologies such as onboard sensors, positioning devices, and communication modules. This includes, but is not limited to, vehicle operating status data, environmental perception data, network status data, system resource data, vehicle-cloud platform data, and human-vehicle interaction data. Operating status data includes, but is not limited to, real-time operating parameters such as vehicle position, speed, acceleration, direction, engine speed, fuel consumption, battery charge, tire pressure, and interior temperature. Environmental perception data includes, but is not limited to, information about the surrounding environment collected by onboard cameras, radar, and LiDAR sensors, such as obstacle distance, pedestrian recognition, traffic light status, road surface slippage, and weather conditions. Network status data includes, but is not limited to, the connection status, signal strength, network bandwidth, signal latency, and packet loss rate of 5G / V2X (Vehicle-to-Everything) communication modules. System resource data includes, but is not limited to, computing power resources and CPU utilization on the vehicle side.

[0071] In practical applications, the vehicle-side control device can first acquire vehicle network data from different sensors and subsystems through multiple interfaces, including but not limited to vehicle operating status data, environmental perception data, network status data, system resource data, vehicle-cloud platform data, and human-vehicle interaction data. These data sources cover visual data (such as road images captured by cameras and driver facial videos), numerical data (such as vehicle speed, following distance, tire pressure, and battery voltage), and event-based data (such as automatic emergency braking triggering and lane departure warning). Simultaneously, the onboard communication module monitors the throughput and stability of the 5G or V2X link in real time, and the power management unit and main control chip report battery levels and CPU usage, respectively. All collected data is timestamped to ensure spatiotemporal alignment of multimodal data in subsequent processing.

[0072] For example, an onboard heterogeneous sensor can collect visual data (224×224 pixel RGB image of driver micro-expression, 1080P frame of road scene), numerical data (vehicle speed such as 120km / h, following distance such as 5m, brake not applied, tire pressure such as 2.5bar, battery level such as 70%), and status event data (collision warning triggered, no abnormalities in system log) at a sampling frequency of 15 frames / second for visual data, 1Hz (hertz) for numerical data, and 500ms (milliseconds) / time for status event data. The collected data is then transmitted to the vehicle-side control device to obtain vehicle network data.

[0073] Step 200: Assess the value level of the vehicle-to-everything (V2X) data and generate a data summary of the V2X data.

[0074] The value level of data is a quantitative representation of the importance of connected vehicle data, typically considering its contribution to driving safety and the timeliness of events. Data summaries are compact representations of connected vehicle data after semantic extraction, retaining key features of important events while significantly reducing data volume.

[0075] Following the previous step, after acquiring the vehicle-to-everything (V2X) data, the vehicle-side control device first preprocesses the synchronized V2X data, including image clarity filtering, numerical normalization, and redundant frame removal, forming standardized input. Subsequently, the vehicle-side control device extracts multi-dimensional key semantic features from the preprocessed V2X data, such as driver eye-closing duration, distance to the vehicle ahead, rapid acceleration events, and abnormal tire pressure. It then generates a joint semantic representation through a cross-modal fusion mechanism. The joint semantic representation is then evaluated according to preset value assessment rules to determine the value level of the V2X data. Simultaneously, a data summary of the V2X data is obtained based on the integrable joint semantic representation. For example, if the V2X data contains high-speed following events accompanied by driver fatigue, the value level of the V2X data is assessed as high value.

[0076] In other embodiments, the value level assessment can also employ machine learning, or a combination of rule engines and machine learning, without limitation. For example, for clearly defined high-risk events (such as collision warnings), the highest value level is directly assigned; for ambiguous situations (such as slow lane changes + slight distraction), the Transformer model is invoked to perform fine-grained value level assessment to determine the value level of the vehicle-to-everything (V2X) data.

[0077] Step 300: Determine the data upload priority of the data summary based on the value level and operational status data.

[0078] Data upload priority is used to characterize the urgency with which the data digest should be transmitted under the current system state. In this embodiment, data upload priority can typically be divided into four levels: low, medium, high, and highest. It is understood that in other embodiments, data upload priority can also be characterized by different numbers, with larger numbers indicating higher value levels.

[0079] Following the previous step, after determining the value level of the vehicle-to-everything (V2X) data, the vehicle-side control equipment can use the value level as the primary basis for priority mapping, combined with operational status data. For example, when the value level is ≥8, the initial priority is set to "high." If the vehicle's battery level is below 20% and there is no external power supply, non-urgent high-value data can be appropriately downgraded to balance resource consumption. The essence of this approach is to map multi-dimensional inputs to specific priority categories, ensuring that critical information is still prioritized even when resources are limited.

[0080] In other embodiments, a priority decision table can be constructed, predefining the priority output corresponding to combinations of value level ranges and environmental states. For example, "high value level + excellent network state → highest priority"; "medium value level + medium network state → medium priority". It is understood that this priority decision table can be updated in real time.

[0081] Step 400: Determine the data upload strategy based on network status data, system resource data, and data upload priority.

[0082] The data upload strategy is a transmission execution plan formulated for the data digest. Specifically, it can include whether to upload immediately, delay upload, cache locally for later transmission, and specific parameters such as the selected communication channel, encryption strength, and retransmission mechanism.

[0083] In practice, after determining the data upload priority, the vehicle-side control equipment can comprehensively consider current network status data such as network bandwidth, system resource data such as computing power, and data upload priority to determine the final data upload strategy. For example, the highest priority data is uploaded immediately regardless of network conditions; high priority data is uploaded immediately when the network is good, and the V2X direct connection channel is activated when the network is weak; medium and low priority data is uploaded in batches when the battery is sufficient and the network is idle.

[0084] In other embodiments, a multi-condition judgment logic based on thresholds can be used to determine the data upload strategy. For example, a network bandwidth threshold and a battery threshold can be set. If the priority is high, the current battery level is greater than the battery threshold, and the current network bandwidth is greater than the network bandwidth threshold, then the data upload strategy is "upload immediately".

[0085] Step 500: Upload the data summary to the server based on the data upload strategy.

[0086] In practical applications, the vehicle-mounted control device can upload the data digest to the server according to the data upload strategy determined in the above steps. For example, if the data upload strategy requires immediate upload, a 5G communication module can be invoked to establish a secure channel, and the data digest can be encapsulated into a standard message format (such as MQTT or HTTP) for transmission. If the strategy is to cache first and then upload, the data digest is first written to a local secure storage area, and then uploaded to the server when the upload conditions are met. Furthermore, after the data digest upload is complete, the vehicle-mounted control device can record a data transmission log for subsequent traceability.

[0087] The aforementioned vehicle-to-everything (V2X) data processing method effectively eliminates redundant information and significantly reduces data transmission volume by assessing the value level of V2X data and generating concise data summaries. It combines value level with real-time operational status data to dynamically determine data upload priority, reducing the practice of blindly transmitting non-critical data when resources are scarce, thereby improving the overall system resource utilization efficiency. Furthermore, based on this data upload priority and the operational environment status, the data upload strategy is jointly decided, achieving adaptive matching between data upload behavior and current vehicle-side capabilities, ensuring the timely upload of critical data. Finally, by uploading lightweight data summaries instead of raw data according to the data upload strategy, not only are communication bandwidth and storage costs significantly saved, but the risk of leakage of sensitive raw information is also reduced. In summary, under limited vehicle-side resource conditions, the above solution balances data validity, transmission timeliness, system stability, and data security, significantly improving the overall efficiency of V2X data upload.

[0088] To improve data processing efficiency and data quality, preprocessing can be performed on the data after acquiring the vehicle network data. In an exemplary embodiment, such as... Figure 3 As shown, step 100 includes:

[0089] Step 110: Obtain raw vehicle network data from multiple data sources, perform data preprocessing on the raw vehicle network data to obtain vehicle network data. Data preprocessing includes at least one of noise reduction, format normalization, and redundant data removal.

[0090] Vehicle-to-everything (V2X) raw data refers to unprocessed data directly collected or generated by various onboard sensors, controllers, and communication modules during vehicle operation. Noise reduction refers to removing invalid or distorted data caused by sensor malfunctions, environmental interference, or transmission errors, such as blurry images or abruptly changing values. Format normalization refers to converting data from different sources, units, or resolutions into a unified numerical range and structural form to facilitate subsequent fusion processing. Redundant data removal refers to identifying and removing data segments that are highly repetitive in time or content and have extremely low information gain, such as tire pressure readings that remain unchanged for multiple consecutive frames or repetitive video frames in static scenes.

[0091] In practice, the vehicle-side control device can synchronously acquire raw vehicle network data from multiple heterogeneous data sources via the CAN bus. This data includes road scene videos output by cameras (such as 1080P, 15fps), micro-expression images captured by driver monitoring cameras (such as 224×224 RGB images), millimeter-wave radar point clouds, vehicle speed and following distance signals transmitted via the CAN bus, and collision warning logs issued by the active safety module. All raw vehicle network data is timestamped at the time of acquisition to ensure that multimodal information is aligned in the time dimension. Subsequently, the vehicle-side control equipment performs end-side (i.e., local-side) data preprocessing, which includes at least one of the following methods: ① Noise denoising: Removing radar false detection points. For visual data, the image sharpness index is calculated. If it is lower than a preset threshold (e.g., 0.8), it is judged as blurry and removed; ② Format normalization: Visual data is compressed to 224×224 pixels, and the pixel value is normalized to [0,1]. For numerical sensor data (e.g., vehicle speed 120km / h), it is normalized to the [0,1] interval through linear mapping to eliminate dimensional differences; For status data such as tire pressure data, if it does not change within 3 consecutive seconds (e.g., constant tire pressure), it is considered redundant data and discarded. It is understood that the equipment can simultaneously perform the above-mentioned noise denoising, format normalization, and redundancy removal operations on the original vehicle network data, or perform at least one of the above preprocessing operations, or perform other operations besides the above processing, such as data format conversion, image processing, etc. The specific operation can be determined according to the actual situation and is not specifically limited here.

[0092] After preprocessing, the raw vehicle network data is transformed into standardized vehicle network data with consistent structure and higher information density, forming a high-quality input tensor that can be used for value assessment and summary generation. Visual features are compressed into 64-dimensional vectors, and numerical and state features are also integrated into feature representations of the same dimension. The entire preprocessing process takes less than 50 milliseconds to meet real-time requirements.

[0093] In this embodiment, by performing at least one of the following preprocessing steps on the original vehicle network data—denoising, format normalization, and redundancy removal—the quality and consistency of the input data are effectively improved while retaining key event information. This provides a reliable foundation for subsequent high-precision value assessment and efficient semantic summary generation, while also reducing the consumption of computing resources and storage bandwidth by invalid data.

[0094] like Figure 4 As shown, in an exemplary embodiment, step 200 includes:

[0095] Step 210: Extract visual semantic features and numerical semantic features from the vehicle network data.

[0096] Step 220: Combine visual semantic features and numerical semantic features to obtain combined semantic features.

[0097] Step 230: Evaluate the value level of the vehicle network data based on the fused semantic features.

[0098] Step 240: Determine the fidelity level of the data digest based on the value level, and generate a data digest of the vehicle network data based on the fidelity level.

[0099] Visual semantic features refer to information extracted from image or video data that characterizes the driver's state or road scene, such as interpretable semantics like fatigue level, inattention, or too close a vehicle ahead. Numerical semantic features refer to state quantities with business or safety significance abstracted from non-visual sensor data (such as vehicle speed, tire pressure, battery level, warning signals, etc.), usually represented as normalized numerical vectors. Fusion semantic features refer to the joint representation generated by associative modeling of visual and non-visual semantic features, reflecting the inherent connections between multimodal contexts. A driving event refers to a situational instance with specific driving significance identified by a combination of one or more semantic features, such as "the driver closes their eyes while driving at high speed." Fidelity level refers to the degree to which the data summary retains the core information of the original high-value event during compression; the higher the level, the more complete the details are retained, and the larger the data volume.

[0100] In specific implementation, the vehicle-side control device can first extract features from the pre-processed vehicle network data: For visual inputs (such as driver facial images and road scene frames), a pre-defined convolutional neural network is called to extract a 64-dimensional visual semantic feature vector. This vector encodes semantics such as "driver fatigue probability 0.8" and "following distance too close confidence 0.9". The semantic feature vector can be represented as V_vis=[0.8 (driver fatigue), 0.9 (following too close),...]. At the same time, for numerical and state inputs (such as vehicle speed, collision warning signs, etc.), a 64-dimensional numerical semantic feature vector is extracted through a fully connected network or Transformer structure, and the numerical semantic feature vector V_num=[0.9 (vehicle speed 120), 0.8 (following distance 5m), 1.0 (collision warning),...]. Subsequently, the device employs a cross-modal attention mechanism for feature fusion: using the visual semantic feature vector V_vis as the query and the numerical semantic feature vector V_num as the key and value, attention weights are calculated and weighted aggregation is performed to generate fused semantic features that reflect "contextual association." For example, "driver fatigue" and "high-speed following" are associated as high-risk driving events, outputting the fused semantic feature V_fusion=[0.95 (collision warning), 0.9 (following too closely),...]. Through the above fused semantic features, "the driver appears fatigued" and "the vehicle is currently following at high speed" can be obtained, thus generating a precise data summary such as "high-risk following: the driver shows signs of fatigue."

[0101] Next, the device can traverse the driving event template library. Each template in the driving event template library defines the semantic combination conditions of a typical driving event. For example, the template for the event "fatigue driving accompanied by high-speed following" can be represented as: (the driver's eye-closing duration is ≥2 seconds or the yawning frequency is ≥1 time / 30 seconds) and the vehicle speed is ≥80km / h and the following distance is ≤1.0 second.

[0102] The device can check whether the current fused semantic features meet the logical conditions of each driving event template. If all sub-conditions of a template are met, it is determined that a driving event has occurred, and a driving event object is instantiated based on the fused semantic features and the event template, including the event type, occurrence timestamp, associated feature values, and original data index. In other embodiments, it can also be based on a large amount of multimodal vehicle network data (including driver videos, road images, CAN signals, and driving event logs) collected in real vehicles or simulations in advance. Then, the multimodal vehicle network data within a preset time window (e.g., 5 seconds) is semantically labeled with driving events (e.g., labeled "fatigue driving," "aggressive following," etc.) by manual means or labeling tools to obtain a labeled dataset. Subsequently, each segment of driving event labeled data in the labeled dataset is converted into a corresponding fused semantic feature sample to form a "feature-label" training sample. Then, the Transformer model (2-3 layers of fully connected network, with classification cross-entropy as the loss function) is trained based on this training sample to minimize the classification cross-entropy loss, thereby training an event recognition model that can accurately predict the probability of driving event categories.

[0103] In practical implementation, the device can acquire raw vehicle-to-everything (V2X) data over a continuous period, segment the raw V2X data according to a preset time window, and then perform subsequent processing on the raw V2X data within each segment. The fused semantic features of the V2X data within each segment are then input into a trained event recognition model. The model determines the probability distribution of various driving event categories (such as "normal driving," "distracted driving," "aggressive following," "fatigue driving," etc.), and selects the driving event category with the highest probability that exceeds a preset confidence threshold, such as 0.7, as the recognition result and outputs it. Next, the device uses a rule engine to bind this category with the fused semantic features of the current moment to obtain a structured driving event. In other embodiments, a hybrid architecture of rules and models can be used. First, the event recognition model identifies the category of the driving event. Then, based on the driving event category, a driving event template corresponding to the category is selected from a driving event template library. Next, based on the driving event template, corresponding elements are extracted from the fused semantic features, and the extracted elements are filled into the driving event template to generate a structured driving event.

[0104] Next, based on the preset multi-dimensional value level evaluation rules, the driving event's comprehensive performance across multiple dimensions is assessed to determine its value level, which can be represented by a score of 0–10. Then, based on the value level, the fidelity level of the corresponding data summary for the driving event is determined. For example, if the value level is ≥8, it is considered a high-value event, and a high fidelity level is set accordingly (e.g., retaining over 90% of core features, compression ratio 15:1); if the value level is ≤3, a low fidelity level is adopted (e.g., only event type tags are retained). Finally, based on the determined fidelity level, the device simplifies or quantifies the fused semantic features to varying degrees, generating a data summary that is size-appropriate and semantically complete for subsequent uploading.

[0105] In this embodiment, driving events are identified by fusing visual and non-visual semantic features, and the fidelity of the data summary is dynamically set according to its value level. This ensures that high-value event information is effectively preserved while achieving adaptive compression of data volume, thereby improving data processing efficiency and the semantic usability of the data summary.

[0106] There are no restrictions on the method used to assess value levels. For example... Figure 5 As shown, in an exemplary embodiment, step 230 includes:

[0107] Step 232: Extract driving events from the fused semantic features, assign weighted scores to driving events from multiple preset dimensions, determine the value score of driving events, determine the value level of driving events based on the value score, and use the value level of driving events as the value level of vehicle network data. The dimensions include at least two of the following: safety dimension, timeliness dimension, business dimension, and scarcity dimension.

[0108] In this embodiment, the safety dimension refers to the degree of correlation between the driving event and driving safety risks, such as whether it involves high-risk situations like collision warnings, brake failures, following too closely, emergency braking, or driver incapacitation. The timeliness dimension refers to the time sensitivity of the driving event information, i.e., whether its value decays rapidly over time, such as real-time traffic incidents or sudden malfunctions. The business dimension refers to the supporting value of the event for application scenarios such as vehicle operation, insurance pricing, remote diagnostics, or user services. The scarcity dimension refers to the frequency of the event's occurrence in historical data; the rarer the event, the higher its scarcity score. The value score is a quantitative value obtained by weighting the above multiple dimensions according to preset weights, used to objectively measure the comprehensive importance of the driving event.

[0109] In practice, the vehicle-side control device can first identify specific driving event instances from the fused semantic features, such as "the driver closes their eyes for 2 seconds while driving at high speed and the following distance is less than the safety threshold." Then, the device evaluates the event's performance across four preset dimensions: In the safety dimension, if the driving event includes a collision warning or high-risk behavior (such as fatigue driving at high speed), it is assigned a normalized score close to 1.0; in the timeliness dimension, if the driving event is a sudden, instantaneous event (such as sudden braking or lane departure), its timeliness score is high; in the business dimension, if the driving event can be used for autonomous driving decisions or V2X communication, it receives a correspondingly high business value score; in the scarcity dimension, by comparing with the local event log database, if this type of combined event has not occurred in the past 30 days, such as driving in extreme weather, it is judged as highly scarce and receives a high scarcity score. Next, the device weights and sums the scores of each dimension according to preset weights (such as safety 0.4, timeliness 0.3, business 0.2, and scarcity 0.1) to obtain a value score ranging from 0 to 10. For example, a fatigued driving incident accompanied by a collision warning might receive a safety score of 0.95 × 0.4 + a timeliness score of 0.9 × 0.3 + a business score of 0.7 × 0.2 + a scarcity score of 0.85 × 0.1 = 0.905, corresponding to a value score of 9.05. Finally, the device can map the value score to a value level according to a preset range: a value score ≥ 8 indicates a high value level, 3 < value score < 8 indicates a medium value level, and a value score ≤ 3 indicates a low value level. Then, a high-fidelity summary can be generated for high-value data, a standard summary for medium-value data, and minimally compressed or discarded data for low-value data.

[0110] For example, the process of judging high-value and low-value data from the dimensions of security, timeliness, business, and scarcity can be seen in Table 1:

[0111] Table 1 Data Value Level Assessment Table

[0112]

[0113] It is understood that in other embodiments, weighted scoring can be performed from at least two of the following dimensions: security, timeliness, business, and scarcity. Alternatively, other dimensions besides the four mentioned above can be introduced for weighted scoring. This is not a unique limitation.

[0114] In this embodiment, by weighting and scoring driving events from multiple dimensions such as safety, timeliness, business, and scarcity, and classifying them into value levels, the importance of data is quantitatively distinguished, providing a unified and scalable evaluation basis for subsequent summary generation, encryption strategy selection, and upload priority decision-making.

[0115] like Figure 6As shown, in an exemplary embodiment, prior to step 400, the method further includes:

[0116] Step 310: Based on the data digest, determine the sensitivity level of the data digest. Based on the sensitivity level, value level, and operational status data, determine the target encryption strategy. Encrypt the data digest according to the target encryption strategy to obtain the encrypted data digest.

[0117] Step 500 includes: Step 510, uploading the encrypted data digest to the server based on the data upload strategy.

[0118] In this embodiment, the sensitivity level refers to the degree of risk to the information carried by the data digest in terms of privacy or security, and can be classified according to whether it contains driver biometrics, vehicle location trajectory, or high-risk driving behavior. The target encryption strategy refers to the encryption algorithm and key management method selected to protect the privacy of the data digest. In this embodiment, different strategies correspond to different computational overheads and security strengths. The encrypted data digest refers to the ciphertext data with confidentiality protection after being processed by the target encryption strategy. In this embodiment, the operational status data can be real-time system parameters that affect the feasibility of encryption and transmission execution, including current network quality, device battery level, processor load, and storage capacity.

[0119] In practice, after generating a data digest, the vehicle-side control device can first determine its sensitivity level based on the content of the generated data digest. For example, it can analyze the semantics of the data digest and determine whether it contains sensitive information of a preset type (which can be identified through keyword matching) based on semantic recognition. Then, based on the recognition results, it can determine the sensitivity level of the data digest. For example, preset elements of highly sensitive information may include driver biometrics, precise geographical location, or events consisting of multiple high-risk driving behaviors (such as fatigue + high speed). If the data digest contains at least one of the highly sensitive information elements, its sensitivity level is determined to be high. If the data digest only contains generalized business status information that does not involve personal identification or driving safety risks (such as "low battery"), its sensitivity level is determined to be low. Subsequently, the device combines this sensitivity level, the value level determined in the previous steps, and the current operating status data (such as whether the battery level is below 20%) to jointly decide on the target encryption strategy.

[0120] Specifically, when the sensitivity level of the data digest is high, high-strength algorithms such as the national standard SM4 or AES-256 are preferred; when the sensitivity level is medium, AES-256 encryption is used; and when the sensitivity level is low, the lightweight AES-128 encryption algorithm is used to save computing power. It is understood that in other embodiments, other encryption algorithms may be used for different sensitivity levels, depending on the specific circumstances, and this is not a unique limitation.

[0121] Furthermore, before encryption, the device and the remote server can collaboratively generate a session key. After two-way verification, the device invokes the hardware security module to encrypt the data digest using the selected target encryption algorithm, outputting the encrypted data digest. Subsequently, when determining the data upload strategy, the original digest will no longer be used. Instead, the encrypted data digest will be used as input, combined with its corresponding data upload priority, network status, and system resource data (such as whether the bandwidth is greater than 5Mbps and whether the CPU load is less than 70%), to decide whether to upload immediately, delay upload, or temporarily store it locally. For example, under high priority and good network conditions, it will be uploaded immediately via the 5G channel; if the network condition is poor and the priority is medium, it will be cached in a secure storage area and retried when conditions improve.

[0122] In this embodiment, the encryption strategy is dynamically determined by combining the sensitivity level and value level of the data digest with the operating environment status. After encryption, the upload strategy is decided collaboratively based on the encrypted digest and the system status. This achieves an adaptive balance between security protection strength and resource consumption, and improves the compliance and execution efficiency of vehicle network data transmission.

[0123] The method for determining the target encryption strategy is not limited. In an exemplary embodiment, determining the target encryption strategy based on sensitivity level, value level, and operational status data includes: matching encryption strategies that match the sensitivity level, value level, and operational status data from a preset encryption strategy decision matrix, and using the matched encryption strategies as the target encryption strategy;

[0124] The target encryption strategy includes encryption algorithms, key length, and key update methods. Different sensitivity levels and different value levels correspond to encryption algorithms of different strengths.

[0125] In this embodiment, the encryption strategy decision matrix refers to a multi-dimensional mapping table pre-configured in the vehicle-side control device. Its rows, columns, and depth dimensions correspond to the classification intervals of sensitivity level, value level, and operating status data, respectively. Each cell stores a complete set of encryption parameter combinations. The key length refers to the number of bits in the encryption key, directly affecting the security strength and computational overhead of the algorithm. The key update method refers to the time- or event-driven key rotation mechanism, such as updating at fixed time intervals (e.g., 30 seconds), based on data volume thresholds, or triggered by highly sensitive events.

[0126] In practice, after generating data summaries, determining sensitivity levels, and classifying value levels, the vehicle-side control equipment further acquires current operating status data, such as real-time parameters like battery level and fuel consumption, and quantifies them into preset categories (e.g., "high range," "medium range," and "low range"). Subsequently, the equipment uses the sensitivity level (high / medium / low), value level (high / medium / low), and operating status data as a ternary index to query the locally stored encryption strategy decision matrix, thereby matching the target encryption strategy. For example, when both the sensitivity and value levels are high, regardless of the range, the strategy of "SM4 algorithm, 128-bit key, 30-second timed update" is matched; when the sensitivity and value are medium, and the range is low, a lightweight strategy of "AES-128, 128-bit key, event-triggered update" is matched to reduce power consumption; if the sensitivity is low but the value is high (e.g., only business indicators but critical for insurance modeling), "AES-256, 256-bit key, session-based update" may be used to balance security and compliance. The matched target encryption strategy explicitly includes three elements: encryption algorithm, key length, and key update method. The key update trigger condition can be at least one of the following: ① updating at a preset frequency according to the decision matrix (e.g., 15s / time, 5min / time); ② sudden change in operating status data (e.g., fuel consumption from low to high); ③ detection of key anomalies (e.g., potential for cracking, verification failure). In other embodiments, the key can also be updated based on network status. For example, the network can be monitored in real time: network bandwidth (hereinafter referred to as bandwidth), latency, and packet loss rate are collected every 500ms and categorized into three levels: "excellent / medium / poor"; if the network quality is excellent (sufficient bandwidth, low latency), the key is updated from the cloud every 30s to ensure security; if the network quality is medium (normal state), it is updated once every 5 minutes, compressing the update packet to save bandwidth; if the network quality is poor (insufficient bandwidth), a local backup key is temporarily used, and batch updates are performed after the network recovers.

[0127] Next, the device calls the corresponding cryptographic engine based on the matched target encryption policy: if SM4 is selected, the national cryptographic hardware acceleration module is enabled; if it is AES series, the software or hardware encryption path is configured according to the key length. Meanwhile, the key update method determines subsequent key management behavior, including timed updates requiring the start of a timer, and event-triggered updates being bound to a high-priority event queue.

[0128] In other embodiments, the device may first classify the current environmental state of the vehicle based on the multi-dimensional environmental parameter evaluation system in Table 2, and then determine the target encryption strategy based on the environmental state and the preset encryption strategy adaptive decision matrix (as shown in Table 3).

[0129] Table 2 Multidimensional Environmental Parameter Assessment System

[0130]

[0131] Table 3 Adaptive Decision Matrix for Encryption Strategy

[0132]

[0133] In this embodiment, by using a preset encryption strategy decision matrix, the sensitivity level, value level and operating status data are jointly mapped to the target encryption strategy, thereby achieving dynamic adaptation of encryption strength, key management method and actual vehicle resource status, and reasonably controlling computing and energy consumption while ensuring data security.

[0134] like Figure 7 As shown, in an exemplary embodiment, the data digest is encrypted according to the target encryption policy to obtain the encrypted data digest, which includes:

[0135] Step 311: If a network connection is available, work with the server to generate a session key and encrypt the data digest using the session key.

[0136] Step 312: In the event that the network is unavailable, encrypt the data digest using a locally cached backup key.

[0137] A session key is a symmetric encryption key temporarily generated for a single or short communication session, valid only within the current data transmission period. A locally cached backup key is an encryption key pre-set through a secure channel or retained from historical sessions and authorized for storage in the vehicle's secure storage area, used as an emergency measure when a new key cannot be obtained in real time.

[0138] In this embodiment, the example uses a remotely deployed cloud server (hereinafter referred to as the cloud). After determining the target encryption strategy, the vehicle-side control device (hereinafter referred to as the end-user) first checks for a valid network connection. If a stable network connection exists (e.g., 5G signal strength is above a threshold and cloud services are accessible), the device immediately initiates a key negotiation request to the server's key distribution center. The key distribution center is a trusted component deployed on the remote server side, responsible for securely generating and distributing encryption keys, used to collaboratively establish a session key with the vehicle-side device. The end-user establishes a secure channel with the cloud's key distribution center through a pre-shared root key (factory-installed and tamper-proof). During the initial connection, an initial session key is negotiated. Subsequent key updates involve the vehicle-side control device generating a first key fragment K1, and the key distribution center generating a second key fragment K2, exchanging their respective key fragments through a secure channel. Both parties then jointly calculate a checksum based on the data digest content, current timestamp, and network status information (e.g., using SHA256 hashing). Each independently verifies the checksum consistency. Only when the checksums match are K1 and K2 concatenated to generate a complete session key. Next, the session key can be loaded into the hardware security module, and the data digest can be encrypted according to the algorithm specified by the target encryption policy (such as SM4 or AES-256), and the encrypted data digest can be output.

[0139] If there is no stable network connection or no network connection (e.g., in a tunnel, underground parking garage, or due to communication module failure or cloud communication anomalies), the device automatically switches to offline mode: it reads a pre-cached backup key from a protected local secure storage area. This key was securely injected by the key distribution center when the vehicle left the factory or when it last successfully connected to the network, and it has an expiration date and usage limits. The device uses this backup key to encrypt the data digest according to the algorithm and key length specified in the target encryption policy, ensuring basic confidentiality protection is maintained even when the network is down. The entire encryption process strictly follows the key update method defined in the target encryption policy: if it is a timed update, a new session key is generated immediately after the network is restored; if it is an event-triggered update, a network update can be attempted first when a highly sensitive event occurs. All key operations are completed in a trusted execution environment or within a hardware security chip to prevent key leakage, and the encrypted data digest only contains the ciphertext of the semantic digest, without carrying the original image or original CAN message, complying with privacy compliance requirements.

[0140] In this embodiment, by cooperating with the server to generate a session key when the network is available and enabling a locally cached backup key when the network is unavailable, the data digest can be effectively encrypted according to the target encryption strategy under various communication conditions, thus maintaining the continuity and reliability of end-to-end secure transmission.

[0141] In one exemplary embodiment, network status data includes network bandwidth and signal strength. Step 400 includes: determining a data upload strategy based on at least one of network bandwidth, signal strength, system resource data, and data upload priority.

[0142] The data upload strategy includes any one of the following: upload immediately, cache and wait for subsequent uploads, batch merge upload, or discard.

[0143] In practical implementation, the optimal data upload strategy can be determined based on four core requirements: minimum bandwidth consumption, minimum upload latency, maximum data security, and maximum digest validity. After obtaining the encrypted data digest and its corresponding upload priority, the vehicle-mounted control device can simultaneously collect current network communication status information and system resource data. Specifically, this includes: acquiring network communication status information (e.g., current 5G bandwidth of 8Mbps, latency of 30ms) and signal strength (e.g., RSRP = -95dBm) through the communication module; and reading system resource data (e.g., CPU load 65%, available computing power 60%) through the power management unit and the main control chip. Subsequently, the device inputs at least one of the aforementioned network status data and system resource data, along with the data upload priority, into a preset multi-objective optimization criterion engine. The engine has a built-in set of configurable decision logic. For example, if the data upload priority is "highest" (e.g., involving collision warning), then regardless of the network conditions, the "upload immediately" strategy is output; if the priority is "high" but the signal strength is below -110dBm, then "caching and waiting for subsequent uploads" is selected, and the digest is added to the local security queue; if multiple low-to-medium priority digests accumulate and the network condition is good (bandwidth > 5Mbps), then "batch merging and uploading" is triggered to reduce connection establishment overhead; when the priority is "low" and the network cannot be connected for a long time, "discarding" is allowed according to the strategy. After determining the data upload strategy in the above manner, the device generates a data upload command and passes the command to the communication scheduling module: if it is an immediate upload, then a secure channel is established, and the encrypted data digest is immediately uploaded to the server; if it is a cached upload, then the encrypted data digest is first written to the encrypted storage area and uploaded when the network and resources are idle; if it is a batch upload, then an aggregation timer or counter is started, and the data digests are uploaded to the server in batches after the time is reached. It is understood that in other embodiments, the data upload strategy can also be set to other strategies according to the actual situation, and is not limited here.

[0144] In this embodiment, by combining network status, system resource status and data upload priority, strategies such as immediate upload, caching, batch merging or discarding can be dynamically selected to ensure timely transmission of high-priority data while rationally allocating limited network and computing resources on the vehicle side.

[0145] As shown Figure 8 In an exemplary embodiment, the method further includes: step 600, receiving feedback information returned by the server for the data digest, and adjusting the generation method of the data digest when the feedback information indicates that the data digest needs to be adjusted.

[0146] The feedback information refers to the response data returned by the server to the vehicle side after evaluating the content quality, information integrity or service availability of the encrypted data digest.

[0147] Specifically, when the vehicle-side control device completes the encryption and upload of the data digest, it continuously monitors the downlink communication channel from the remote server. After the server receives the encrypted data digest, it can first perform integrity verification and legality verification on the encrypted data digest. After the integrity verification and legality verification pass, it decrypts the encrypted data digest with the corresponding key, and performs parsing and evaluation. For example, it evaluates the feature retention degree of the uploaded data digest. If the feature retention degree of the digest is 95%≥90%, it is determined that the data digest is qualified, and the data digest is stored in the security warning database to support the training of the autonomous driving model. Then, it generates feedback information such as "the digest is qualified and no parameter adjustment is required" and feeds it back to the vehicle-side control device. At this time, the vehicle-side control device does not need to adjust the generation method of the data digest. Otherwise, it generates feedback information "the digest is unqualified and parameter adjustment is required" and feeds it back to the vehicle-side control device, so that the vehicle-side control device adjusts the generation method of the data digest until a qualified data digest is uploaded. In addition, after generating the data digest on the vehicle-side control device side, it can also perform real-time self-checking from dimensions including feature retention degree, compression efficiency, and service adaptability: For example, the self-checking based on the feature retention degree can be: scanning the original vehicle networking data, identifying event identifiers, and based on the identified event identifiers, extracting discrete events and preset key indicator data (such as speed, driver's face image, etc. data), and then constructing the extracted data into a binary or quantized first feature vector. Then, since the data digest itself is represented in the form of a feature vector, the device can also extract discrete events and key indicator data based on the event identifier, and then construct the proposed data into a second feature vector. Then, a weighted hybrid similarity model can be used to calculate the similarity between the first feature vector and the second feature vector. For example, for the event feature S event : Calculate the proportion of the matching items in the total number of original events; for the numerical feature S numeric , use the normalized absolute error formula (S numeric = 1 - |original value - digest value| / feature maximum range) to obtain the fidelity. Then, according to the preset business importance, assign weights (such as the security event weight w1 is 0.7 and the numerical weight w2 is 0.3), and calculate the similarity in a weighted average manner: S total = w1 × S event+w2×S numeric If the similarity between the two is ≥ 90%, it is determined to be qualified. It can be understood that in other embodiments, the first feature vector and the second feature vector can also be represented as the same-dimensional dense vectors (such as embedding vectors or normalized feature vectors), and then the cosine similarity algorithm, Euclidean distance or edit distance is used to calculate the similarity between the first feature vector and the second feature vector, which is not uniquely limited here. The self-check process based on compression efficiency can be: the amount of original vehicle networking data / the amount of data summary data ≥ 10:1 (such as 100MB of original data → 5MB of summary), and it is determined to be qualified. The self-check based on service adaptability can be: First, call the downstream service model corresponding to this data summary (such as the "too close following" recognition model), use the current data summary as the input, perform a forward inference once, obtain the prediction result and confidence of the service event, and then compare this prediction confidence with a preset service performance threshold (such as 0.95); if the confidence reaches or exceeds the threshold, it is determined that this data summary has sufficient semantic integrity and can effectively support the target service function, and the service adaptability of the data summary is determined to be qualified. If any one of the above three determination conditions is not satisfied, it is determined that the data summary is unqualified and the reason for disqualification is recorded. Then, trace back to the summary generation link according to the non-compliance reason. If the information loss is caused by too low fidelity, the fidelity level is increased (such as adjusted from "medium" to "high") to retain more original semantic details; if the feature fusion strategy is improper, the fusion mode is switched (such as enhancing the visual-numerical cross-modal attention weight); then, the vehicle-side control device re-executes feature extraction and fusion based on the same original vehicle networking data with the adjusted parameters, and regenerates a new data summary; then, the above local self-check is performed on the new data summary again. Once the new data summary passes the self-check, lock this version for subsequent encryption and uploading, and record the current optimization parameters in the policy cache for reference by similar events, so as to achieve closed-loop and iterative quality improvement of the data summary.

[0148] In this embodiment, by receiving the feedback information returned by the server and dynamically adjusting the data summary generation method and data upload strategy accordingly, the collaborative optimization of the end-side processing logic and the cloud usage requirements is achieved, and the information effectiveness of the semantic summary and the resource adaptability of the upload behavior are improved.

[0149] To make a clearer description of the vehicle networking data processing method provided in this application, the following describes it in combination with the embodiments in the high-sensitive data transmission scenario of the vehicle driving on the high-speed classified section and the low network transmission rate scenario of the underground garage:

[0150] When a vehicle enters a high-speed, sensitive section of road, the vehicle-side control equipment (also referred to as the equipment) first acquires raw vehicle network data synchronously from multiple onboard sensors. This includes 1080P road video frames (15fps) captured by cameras, 224×224 pixel images of the driver's face, following distance information provided by millimeter-wave radar, and real-time reporting of vehicle speed, acceleration, and "following too closely warning" event signals from the CAN bus. Then, a unified timestamp is added to all the raw vehicle network data collected, forming a multi-source vehicle network dataset with spatiotemporal alignment.

[0151] Subsequently, the device performs edge-side preprocessing on the multi-source vehicle network dataset: removing blurry images (clarity <0.8), normalizing vehicle speed to the [0,1] interval, and discarding redundant data that has not changed within 3 seconds, such as tire pressure. Next, visual semantic features (such as "following distance too close, confidence 0.92") and non-visual semantic features (such as "vehicle speed 110km / h" "alarm triggered") are extracted respectively. The two types of features are fused through a cross-modal attention mechanism to generate a data summary representing "following too closely at high speed and in a confidential geographical area". Based on this summary, the device performs a weighted score on it in four dimensions: safety (0.4), timeliness (0.3), business (0.2), and scarcity (0.1), resulting in a value score of 9.1, which is classified as high value level; at the same time, due to the inclusion of confidential locations and high-risk driving behaviors, the sensitivity level is determined to be high.

[0152] Next, the device queries the local encryption policy decision matrix, inputs high sensitivity, high value, and optimal network / computing power status, and matches the target encryption policy: "Chinese national cryptographic SM4 algorithm, 128-bit key, 30-second update frequency." Since the V2X network is available, the device initiates key negotiation with the key distribution center on the cloud server: a key fragment K1 is generated locally, and the cloud server returns a key fragment K2. Both parties independently calculate the SHA256 checksum based on the current digest content, timestamp, and network status. After verification, they are concatenated to form the session key. Then, the device divides the semantic digest into blocks of fixed size and encrypts each block using the SM4 algorithm to obtain the encrypted data digest.

[0153] Next, based on the device's overall data upload priority ("high"), network status ("excellent"), and computing power (60% - "sufficient"), the data upload strategy is determined to be "immediate upload," and the encrypted digest is sent to the server via the V2X channel. Subsequently, every 30 seconds, a key update process is automatically triggered to renegotiate the session key to maintain high security. When the high-precision map detects a vehicle leaving a sensitive road section, the geographical location sensitivity drops to medium. The sensitivity level of subsequent similar events is adjusted accordingly, and the device automatically switches the encryption strategy to "AES-256, 128-bit key, 5-minute update," completing dynamic security adaptation from highly sensitive to moderately sensitive environments, ensuring reliable upload of high-value, highly sensitive data under optimal security and resource conditions.

[0154] If a vehicle enters an underground parking garage, the CAN bus continuously reports numerical data such as engine operating parameters, mileage, and historical fuel consumption. The device acquires the raw vehicle network data at the current moment and detects that the current network status is weak (bandwidth only 1Mbps, signal strength -115dBm), the remaining battery is 25%, the CPU load rate has reached 80% (computing power remaining 20%), and the overall system resources are in a limited state. Similarly, all raw data is tagged with a uniform timestamp. Subsequently, the device performs lightweight preprocessing on the collected raw vehicle network data: removing duplicate periodic reports (such as instantaneous fuel consumption that has not changed for 10 consecutive seconds), normalizing the historical fuel consumption statistics to the [0,1] interval, and generating a concise data summary in the same way. Since the data did not involve security incidents, the device determined it to be of low sensitivity. Furthermore, due to its status as routine business statistics, low scarcity, and weak timeliness, a comprehensive four-dimensional score (security 0.1, timeliness 0.2, business 0.5, scarcity 0.2) yielded a value score of 2.3, classifying it as low-value and assigning it a "low" data upload priority. Subsequently, based on its low sensitivity, low value level, and current operating environment (poor network, low battery, poor computing power), the device queried the encryption strategy decision matrix and matched an emergency encryption strategy: "AES-128 simplified algorithm, 128-bit key, pause key updates." Due to unstable network connectivity and inability to reliably access the server key distribution center, the device automatically activated a pre-cached local backup key in the secure storage area, and then used the AES-128 algorithm to quickly encrypt the simplified data digest, generating the encrypted data digest.

[0155] Next, considering the low data upload priority and resource constraints, the device, based on multi-objective optimization principles, determines that transmission is not advisable at this time and should be "cached and awaited for subsequent uploads." Therefore, the encrypted digest is written to a protected local queue and marked "to be processed in batches after network recovery." While the vehicle continues to drive in the underground parking garage, the system does not attempt to upload or update the key to conserve power and computing power. When the vehicle leaves the underground parking garage, the communication module detects that the network status has recovered to a moderate level and the battery level has risen above 30%. The device immediately triggers the cached data processing procedure: packaging the low-priority encrypted digests (which may contain multiple historical statistical records) accumulated in the queue into data packets and re-establishing a secure channel with the server. At this time, key negotiation is initiated simultaneously, completing the exchange and bidirectional verification of K1 / K2 key fragments with the server's key distribution center, updating the session key, and, after confirming channel security, uploading the batch data to the server in one go via a 5G or V2X link. After the upload is complete, the local cache is cleared, the key status is reset, and the system returns to normal policy mode from the emergency strategy, completing a complete closed-loop process from weak network emergency caching to efficient backhaul after network recovery.

[0156] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.

[0157] Based on the same inventive concept, this application also provides a vehicle network data processing device for implementing the above-described vehicle network data processing method. The solution provided by this device is similar to the implementation described in the above method; therefore, the specific limitations in one or more vehicle network data processing device embodiments provided below can be found in the limitations of the vehicle network data processing method described above, and will not be repeated here.

[0158] In one exemplary embodiment, such as Figure 9As shown, a vehicle-to-everything (V2X) data processing device 700 is provided, including: a data acquisition module 710, a summary generation module 720, a priority determination module 730, a strategy determination module 740, and a data upload module 750, wherein:

[0159] The data acquisition module 710 is used to acquire vehicle network data, which includes operating status data, network status data, and system resource data.

[0160] The summary generation module 720 is used to assess the value level of vehicle-to-everything (V2X) data and generate a data summary of the V2X data.

[0161] The priority determination module 730 is used to determine the data upload priority of the data digest based on the data digest, value level, and operational status data.

[0162] The strategy determination module 740 is used to determine the data upload strategy based on network status data, system resource data, and data upload priority.

[0163] The data upload module 750 is used to upload data summaries to the server based on the data upload strategy.

[0164] In some exemplary embodiments, the summary generation module 720 is further configured to extract visual semantic features and numerical semantic features from the vehicle network data, fuse the visual semantic features and numerical semantic features to obtain fused semantic features, evaluate the value level of the vehicle network data based on the fused semantic features, determine the fidelity level of the data summary according to the value level, and generate a data summary of the vehicle network data according to the fidelity level.

[0165] In some exemplary embodiments, the summary generation module 720 is further configured to extract driving events from the fused semantic features, perform weighted scoring on the driving events from multiple preset dimensions, determine the value score of the driving events, the dimensions include at least two of the following: safety dimension, timeliness dimension, business dimension and scarcity dimension, and determine the value level of the driving events based on the value score, and use the value level of the driving events as the value level of the vehicle network data.

[0166] like Figure 10 As shown, in some exemplary embodiments, the apparatus further includes a data encryption module 722, which is used to determine the sensitivity level of the data digest, determine a target encryption strategy based on the sensitivity level, value level and operating status data, encrypt the data digest according to the target encryption strategy, and obtain an encrypted data digest. The data upload module 750 is also used to upload the encrypted data digest to the server based on the data upload strategy.

[0167] In some exemplary embodiments, the data encryption module 722 is further configured to match a target encryption strategy that matches the sensitivity level, value level, and operating status data from a preset encryption strategy decision matrix; wherein, the target encryption strategy includes an encryption algorithm, a key length, and a key update method, and different sensitivity levels and different value levels correspond to encryption algorithms of different strengths.

[0168] In some exemplary embodiments, the data encryption module 722 is further configured to, when a network connection is available, work with the server to generate a session key and encrypt the data digest using the session key, and when the network is unavailable, encrypt the data digest using a locally cached backup key.

[0169] In some exemplary embodiments, the network status data includes network bandwidth and signal strength. The priority determination module 730 is further configured to determine a data upload strategy based on at least one of network bandwidth, signal strength, system resource data, and data upload priority. The data upload strategy includes any one of immediate upload, caching and waiting for subsequent uploads, batch merging uploads, or discarding.

[0170] In some exemplary embodiments, the apparatus further includes a data adjustment module 760, configured to receive feedback information from the server regarding the data digest, and adjust the data digest generation method if the feedback information indicates that the data digest needs to be adjusted.

[0171] In some exemplary embodiments, the data acquisition module 710 is further configured to acquire raw vehicle network data from multiple data sources, perform data preprocessing on the raw vehicle network data to obtain vehicle network data, wherein the data preprocessing includes at least one of noise reduction, format normalization and redundant data removal.

[0172] Each module in the aforementioned vehicle-to-everything (V2X) data processing device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the corresponding operations of each module.

[0173] In one exemplary embodiment, a vehicle-side control device is provided, the internal structure of which can be shown in the following diagram. Figure 11 As shown, the vehicle-mounted control device includes a processor and a memory. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium storing a computer program. When executed by the processor, the computer program implements a vehicle-to-everything (V2X) data processing method.

[0174] Those skilled in the art will understand that Figure 11 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer equipment (vehicle-side control equipment) to which the present application is applied. The specific computer equipment may include more or fewer components than shown in the figure, or combine certain components, or have different component arrangements.

[0175] In one exemplary embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above-described method embodiments.

[0176] In one exemplary embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps in the above-described method embodiments.

[0177] In one exemplary embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above-described method embodiments.

[0178] The user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0179] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program mentioned can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0180] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0181] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method for processing vehicle network data, characterized in that, The method includes: Acquire vehicle network data, which includes operating status data, network status data, and system resource data; Assess the value level of the connected vehicle data and generate a data summary of the connected vehicle data; The data upload priority of the data summary is determined based on the value level and the operational status data. Based on the network status data, system resource data, and data upload priority, a data upload strategy is determined. The data summary is uploaded to the server based on the data upload strategy.

2. The method according to claim 1, characterized in that, The process of evaluating the value level of the vehicle-to-everything (V2X) data and generating a data summary based on the V2X data includes: Visual semantic features and numerical semantic features are extracted from the vehicle network data; By fusing the visual semantic features and the numerical semantic features, a fused semantic feature is obtained; The value level of the vehicle network data is evaluated based on the fused semantic features. Based on the value level, the fidelity level of the data digest is determined, and a data digest of the vehicle network data is generated based on the fidelity level.

3. The method according to claim 2, characterized in that, The evaluation of the value level of the vehicle-to-everything (V2X) data based on the fused semantic features includes: The driving events in the fused semantic features are extracted, and the driving events are weighted and scored from multiple preset dimensions to determine the value score of the driving events. The dimensions include at least two of the following: safety dimension, timeliness dimension, business dimension, and scarcity dimension. Based on the value score, the value level of the driving event is determined, and the value level of the driving event is used as the value level of the vehicle network data.

4. The method according to claim 2, characterized in that, Before determining the data upload strategy based on the network status data, system resource data, and data upload priority, the method further includes: Determine the sensitivity level of the data digest; The target encryption strategy is determined based on the sensitivity level, the value level, and the operational status data. The data digest is encrypted according to the target encryption strategy to obtain the encrypted data digest. Uploading the data digest to the server based on the data upload strategy includes: The encrypted data digest is uploaded to the server based on the data upload strategy.

5. The method according to claim 4, characterized in that, The step of determining the target encryption strategy based on the sensitivity level, the value level, and the operational status data includes: The encryption strategy that matches the sensitivity level, the value level, and the operating status data is selected from the preset encryption strategy decision matrix, and the selected encryption strategy is used as the target encryption strategy. The target encryption strategy includes encryption algorithms, key lengths, and key update methods. Different sensitivity levels and different value levels correspond to encryption algorithms of different strengths.

6. The method according to claim 4, characterized in that, The step of encrypting the data digest according to the target encryption policy includes: In the presence of a network connection, a session key is generated in collaboration with the server, and the data digest is encrypted using the session key; In the event of network unavailability, the data digest is encrypted using a locally cached backup key.

7. The method according to any one of claims 1 to 6, characterized in that, The network status data includes network bandwidth and signal strength. The process of determining a data upload strategy based on the network status data, system resource data, and the data upload priority includes: A data upload strategy is determined based on at least one of the network bandwidth, signal strength, and system resource data, as well as the data upload priority. The data upload strategy includes any one of the following: immediate upload, caching and waiting for subsequent uploads, batch merging uploads, or discarding.

8. The method according to any one of claims 1 to 6, characterized in that, The method further includes: Receive feedback information regarding the data digest returned by the server; If the feedback indicates that the data digest needs adjustment, the method of generating the data digest shall be adjusted.

9. The method according to any one of claims 1 to 6, characterized in that, The acquisition of vehicle network data includes: Obtain raw vehicle network data from multiple data sources; The original vehicle network data is preprocessed to obtain the vehicle network data. The data preprocessing includes at least one of noise reduction, format normalization, and redundant data removal.

10. A vehicle-end control device, comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 9.

Images