Vehicle-mounted data grading processing method, system, equipment and medium

Abstract

The invention provides a vehicle-mounted data grading processing method, system, device and medium, the method is cooperatively realized by a cloud end and a terminal device, and the method specifically comprises the following steps: the cloud end generates a structured configuration file containing an acquisition signal, a data type, a transmission condition, a priority and a compression rule based on a service scene, a first processor of the terminal equipment analyzes a received structured configuration file to generate an acquisition white list, a second controller filters controller messages according to the white list, executes double verification of cyclic redundancy check and counter tamper-proofing, and transmits valid data passing the verification in a hierarchical manner according to priorities, and a cloud terminal performs hierarchical decompression analysis on the received data and sends the analyzed data to a server. A historical data supplement mechanism is triggered when the data is abnormal, and the terminal equipment responds to the request to upload data in a specified time period and performs compensation analysis; according to the method, the collection flexibility is realized through dynamic configuration, and the problems of high computing power pressure of terminal equipment, non-uniform network transmission distribution and low cloud computing power utilization rate are solved.

Description

Technical Field

[0001] The present application relates to the field of data processing technology, and in particular to a method, system, device and medium for hierarchical processing of vehicle-mounted data. Background Art

[0002] With the rapid development of intelligent connected vehicle technology, electronic and electrical architectures are rapidly evolving towards domain controllers and central computing platforms, driving a leapfrog upgrade from Level 2+ to Level 3 / L4 autonomous driving. In this context, connected vehicle service scenarios are rapidly expanding, encompassing innovative business models such as real-time navigation optimization, battery health monitoring, and predictive maintenance. The cloud-based aggregation of massive amounts of terminal data is reshaping the automotive industry value chain, placing higher demands on data processing efficiency and system reliability.

[0003] Currently, big data reporting from vehicle-mounted terminals has become a core function. Existing technologies typically distribute configuration files from the cloud to instruct terminals to collect CAN bus data and upload it according to the protocol. Alternatively, trigger algorithms are built in the cloud and distributed to the vehicle via a vehicle-cloud link. The terminal (i.e., the vehicle) then collects sensor data based on the algorithm and uploads it for storage. This approach commonly suffers from issues such as excessive terminal computing power, uneven network transmission load, and insufficient cloud computing power utilization. Summary of the Invention

[0004] In view of the above-mentioned shortcomings of the prior art, the present application provides a method, system, device and medium for vehicle-mounted data hierarchical processing to solve the above-mentioned technical problems.

[0005] The present application provides a method for hierarchical processing of in-vehicle data, which is executed by the cloud, including: issuing a structured configuration file to a terminal device, wherein the structured configuration file is generated based on a target business scenario and includes a signal identifier to be collected, a data type, a transmission trigger condition, a data priority, and a compression rule; receiving data collected by the terminal device, wherein the data is parsed by a first processor in the terminal device to generate a collection whitelist by parsing the structured configuration file, and then uploaded after filtering and verification according to the collection whitelist by a second controller; dividing the received data into first data, second data, and third data in order of priority from high to low, and performing hierarchical processing according to a hierarchical strategy, wherein the hierarchical strategy corresponding to the first data includes real-time triggering, decompression, and business analysis; the hierarchical strategy corresponding to the second data includes starting decompression analysis when network resources meet preset conditions; the hierarchical strategy corresponding to the third data includes performing offline analysis of historical data after decompression; when the analysis detects any data abnormality, initiating a historical data supplement request to the terminal device and performing compensation analysis.

[0006] In one embodiment of the present application, the generation of the structured configuration file includes: establishing data timeliness constraint rules including transmission delay, throughput and service quality level based on the business demand indicators of the target business scenario; constructing a data processing framework based on the data timeliness constraint rules, determining the original data fields and their precision parameters, and the original data fields cover vehicle control signal sets or independent acquisition signals; developing structured data definition specifications to generate a structured configuration file that describes the physical identification of the data source, signal acquisition cycle and event trigger conditions.

[0007] In one embodiment of the present application, the hierarchical processing includes: setting a network bandwidth utilization threshold interval, triggering decompression analysis of the second priority data when the bandwidth utilization is monitored in real time to be lower than the lower threshold; compressing the third priority historical data, and generating a transmission file package according to the preset fragmentation rules; performing batch transmission based on a reliable transmission channel, and dynamically adjusting the fragment size and transmission rate based on network status feedback.

[0008] In one embodiment of the present application, a historical data supplement request is initiated to a terminal device and a compensation analysis is performed, including: when a preset abnormal operating condition is detected in the data stream, an incremental data request instruction is generated according to the abnormality type and sent to the terminal device; historical data packets of a specified time period uploaded by the terminal device are received, and the historical data packets of the specified time period are merged; an offline batch job is started to perform compensation analysis on the merged data, and a complete analysis result of the target business scenario is output.

[0009] The present application provides a method for hierarchical processing of in-vehicle data, which is executed by a terminal device, including: receiving a structured configuration file sent from the cloud, the structured configuration file being generated based on a target business scenario and including a signal identifier to be collected, a data type, a transmission trigger condition, a data priority, and a compression rule; parsing the structured configuration file by a first processor of the terminal device to generate a data collection whitelist, the collection whitelist including signal collection frequency and accuracy parameters; filtering controller messages generated by a second controller of the terminal device based on the data collection whitelist, and performing integrity verification on data that meets the conditions; performing differentiated transmission according to the data priority: first-priority data is triggered and reported to the cloud in real time; second-priority data is reported with a delay when network resources meet preset conditions; third-priority historical data is compressed and uploaded in batches; and in response to a historical data supplement request initiated by the cloud, uploading historical data of a specified time period that matches the historical data supplement request.

[0010] In one embodiment of the present application, a structured configuration file is parsed to generate a data acquisition whitelist, including: parsing the signal acquisition frequency parameters defined in the structured configuration file to generate an acquisition whitelist data structure containing an adjustable acquisition frequency range; synchronizing the acquisition whitelist to a second controller that performs message filtering through a preset bus communication protocol, and executing an acquisition whitelist integrity protection mechanism during the synchronization process; establishing a double cache strategy to store new and old versions of the acquisition whitelist to ensure that the second controller obtains the latest acquisition strategy in real time; and dynamically adjusting the signal acquisition period according to the acquisition frequency parameters updated in the structured configuration file.

[0011] In one embodiment of the present application, based on the collection whitelist filtering controller message, integrity verification is performed on the qualified data, including: receiving the original message sent by the second controller, and the original message is received through the controller local area network and the interface of the customized vehicle communication protocol; performing a cyclic redundancy check on the message data in the collection whitelist to verify the transmission integrity of the data frame; performing a counter anti-tampering verification on the data that passes the cyclic redundancy check to detect the continuity and authenticity of the data packet; synchronizing the data stream that passes the integrity verification to the first processor in real time for subsequent hierarchical transmission processing.

[0012] The present application provides a vehicle-mounted data hierarchical processing system, the system includes a cloud and a terminal device, wherein: the cloud includes a configuration generation module, a hierarchical processing engine, and an anomaly compensation module; the configuration generation module is used to generate a structured configuration file based on the target business scenario, and the structured configuration file includes a signal identifier to be collected, a data type, a transmission trigger condition, a data priority, and a compression rule; the hierarchical processing engine is configured to perform hierarchical processing according to a hierarchical strategy, wherein the hierarchical strategy corresponding to the first data includes real-time triggering, decompression, and business analysis; the hierarchical strategy corresponding to the second data includes starting decompression analysis when network resources meet preset conditions; the hierarchical strategy corresponding to the third data includes performing offline analysis of historical data after decompression; the anomaly compensation module is used to notify the terminal device when any data anomaly is detected. Initiate a historical data supplement request and perform compensation analysis on the supplemented data; the terminal device includes a first processor, a second controller, and a communication interface module; the first processor is configured to parse the structured configuration file sent from the cloud and generate an acquisition whitelist containing signal acquisition frequency and accuracy parameters; perform differentiated transmission control according to data priority: report first priority data in real time, report second priority data with a delay when the network meets the conditions, and upload third priority historical data in batches after compression; the second controller is used to filter the generated controller message based on the acquisition whitelist, perform cyclic redundancy check and counter anti-tampering verification on the filtered data, and synchronize the verified data stream to the first processor; the communication interface module is used to respond to the historical data supplement request from the cloud and upload historical data packets for a specified time period.

[0013] The present application provides an electronic device, which includes: one or more processors; a storage device for storing one or more programs, and when the one or more programs are executed by the one or more processors, the electronic device implements the above-mentioned vehicle data hierarchical processing method.

[0014] The present application provides a computer-readable storage medium, characterized in that a computer program is stored thereon. When the computer program is executed by a processor of a computer, the computer is enabled to execute the above-mentioned vehicle data classification processing method.

[0015] Beneficial effects of the present application: The present application proposes a hierarchical processing solution for in-vehicle data, which effectively solves the deficiencies of existing technologies in terms of flexibility, resource allocation and fault tolerance. Among them, the cloud dynamically generates a structured configuration file based on the business scenario, supports flexible adjustment of the acquisition signal, transmission conditions and compression rules, so as to achieve precise adaptation of the data acquisition scope to business needs; in the terminal device, the first processor parses the configuration to generate an acquisition whitelist, the second controller filters the controller message according to the whitelist, and performs cyclic redundancy check and counter anti-tampering double verification, only processing valid data, significantly reducing the computing power consumption of the terminal device. In addition, for network transmission, the solution adopts a hierarchical strategy (real-time transmission, delayed transmission, file segmentation upload) to optimize transmission efficiency and alleviate high-priority data congestion. The cloud classifies and decompresses the received data to reduce the burden of redundant processing, and at the same time improves analysis efficiency through multi-version data merging and offline batch processing. When key signals are missing or the model is iterated, the cloud triggers the historical data retransmission mechanism, and the terminal device responds to the request to upload the data packet for the specified time period to ensure data integrity and analysis reliability. In summary, this method achieves efficient utilization of terminal device computing power, balanced distribution of network transmission, and improved cloud computing power utilization through the collaborative design of dynamic configuration, resource optimization, and abnormality compensation, providing efficient and secure technical support for data governance of intelligent connected vehicles.

[0016] It should be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] The accompanying drawings are incorporated into and constitute a part of the specification, illustrating embodiments consistent with the present application and, together with the specification, serving to explain the principles of the present application. It is obvious that the drawings described below are merely some embodiments of the present application, and a person of ordinary skill in the art can derive other drawings based on these drawings without inventive effort. In the drawings:

[0018] Figure 1is a schematic diagram of an implementation environment of a vehicle-mounted data hierarchical processing method according to an exemplary embodiment of the present application;

[0019] Figure 2 1 is a signal timing diagram of a vehicle-mounted data hierarchical processing method according to an exemplary embodiment of the present application;

[0020] Figure 3 is a flowchart of a method for hierarchical processing of in-vehicle data executed by the cloud, according to an exemplary embodiment of the present application;

[0021] Figure 4 is a flowchart of a vehicle data hierarchical processing method executed by a terminal device according to an exemplary embodiment of the present application;

[0022] Figure 5 is a block diagram of a vehicle-mounted data hierarchical processing system shown in an exemplary embodiment of the present application;

[0023] Figure 6 A schematic diagram of the structure of a computer system suitable for implementing an electronic device according to an embodiment of the present application is shown. DETAILED DESCRIPTION

[0024] The following will describe the embodiments of the present application with reference to the accompanying drawings and preferred embodiments. Those skilled in the art can easily understand the other advantages and effects of the present application from the contents disclosed in this specification. The present application can also be implemented or applied through other different specific embodiments, and the details in this specification can also be modified or changed in various ways based on different viewpoints and applications without departing from the spirit of the present application. It should be understood that the preferred embodiments are only for the purpose of illustrating the present application and are not intended to limit the scope of protection of the present application.

[0025] It should be noted that the illustrations provided in the following embodiments are only schematic illustrations of the basic concept of the present application. Therefore, the illustrations only show components related to the present application and are not drawn according to the number, shape and size of components in actual implementation. In actual implementation, the type, quantity and proportion of each component can be changed at will, and the component layout type may also be more complicated.

[0026] In the following description, a large number of details are discussed to provide a more thorough explanation of the embodiments of the present application. However, it is obvious to those skilled in the art that the embodiments of the present application can be implemented without these specific details. In other embodiments, well-known structures and devices are shown in the form of block diagrams rather than in detail to avoid making the embodiments of the present application difficult to understand.

[0027] Figure 1 It is a schematic diagram of the implementation environment of the vehicle data hierarchical processing method shown in an exemplary embodiment of the present application.

[0028] like Figure 1 As shown, the implementation environment of the vehicle data hierarchical processing method includes a cloud 110 (i.e., a vehicle cloud platform) and a terminal device 120, wherein the terminal device includes a first processor 121 and a second controller 122.

[0029] The cloud 110 generates a structured configuration file based on the business scenario, which includes the acquisition signal, data type, transmission conditions, priority and compression rules, and supports dynamic adjustment to adapt to the needs of different scenarios. The first processor 121 downloads and parses the structured configuration file from the cloud 110, generates a data acquisition whitelist, synchronizes it to the second controller 122 through a custom protocol, and uses the SecOC mechanism to verify the integrity to ensure that the acquisition strategy is updated in real time. The second controller 122 filters the raw data from multimodal sensors (such as front / surround view cameras, millimeter wave radars, etc.) according to the whitelist, performs cyclic redundancy check (CRC) and RollingCounter (rolling counter) anti-tampering double verification, and only retains valid data. The verified data is transmitted in a hierarchical manner according to priority (ASIL-D / ASIL-B / QM): high-priority real-time data is reported immediately through event triggering, low-priority data is transmitted with intelligent delay according to network bandwidth utilization, and non-real-time historical data is packaged using the LZMA high compression algorithm and supports dual-channel TCP transmission. Cloud 110 classifies, decompresses, and analyzes the received data. When it detects the absence of key signals or model iterations, it triggers a historical data retransmission mechanism, sending incremental data requests to the terminal device. The terminal device responds and uploads data packets for a specified time period. Compensatory analysis is achieved through data lake merging and offline batch processing. SecOC (Secure Onboard Communication) is a secure communication mechanism defined in the AUTOSAR (AUTomotiveOpen System ARchitecture) standard. It is used to ensure the security of communications between onboard electronic control units and prevent security threats such as tampering and replay attacks.

[0030] It can be understood that this implementation environment significantly reduces the computing power consumption of terminal devices, optimizes network resource allocation, and improves cloud computing power utilization and data integrity assurance capabilities through the collaborative design of dynamic configuration, hierarchical transmission and abnormal compensation.

[0031] Figure 2 1 is a signal timing diagram of a vehicle-mounted data hierarchical processing method shown in an exemplary embodiment of the present application.

[0032] In one embodiment of the present application, Figure 2As shown, the present application is specifically applied to a specific real-time environment, in which the cloud is defined as a car cloud platform, the terminal device is a car system terminal device, the first processor is an MPU (MicroProcessor Unit), and the second controller is an MCU (MicroController Unit). The process steps of the vehicle data hierarchical processing are as follows: First, a communication link is established between the MCU and the MPU through the SPI bus (Serial Peripheral Interface Bus), and the MPU and the car cloud platform establish a remote connection through the HTTPS channel, providing a basis for subsequent data interaction; then, after the MPU downloads the structured configuration file from the car cloud platform, it parses and generates a data acquisition whitelist, and synchronizes the whitelist to the MCU through the SPI bus, so that the MCU can filter the messages from the sensor or controller according to the whitelist, perform verification operations (such as CRC and RollingCounter verification), retain only valid data, and synchronize the filtered data to the MPU through the SPI bus, forming a solid line data flow from the MCU to the MPU. Next, after the MPU stores the received data locally, it uploads high-priority (ASIL-D) data to the car-cloud platform in real time via a solid arrow, enabling instant transmission triggered by an event. Alternatively, the MPU delays uploading low-priority (ASIL-B) data to the car-cloud platform via a solid arrow based on the network status, with the dashed arrow marking the network bandwidth utilization threshold (e.g., <30%) as a trigger condition. Alternatively, the car-cloud platform sends a historical data reporting request to the MPU via a dashed arrow, and the MPU responds by uploading historical data packets for a specified period to the car-cloud platform via a solid arrow. Finally, the car-cloud platform analyzes the received data and feeds the analysis results back to the MPU via a dashed arrow, forming a closed-loop control link and optimizing subsequent data collection and transmission strategies.

[0033] In a specific embodiment of the present application, the implementation process of the vehicle data hierarchical processing method is as follows:

[0034] First, the car cloud platform generates a structured configuration file based on business scenarios (such as tunnel driving and underground garage identification), and sends the structured configuration file containing the acquisition signal, data type, transmission conditions, priority, and compression rules to the terminal device MPU through the HTTPS channel. After parsing the structured configuration file, the MPU dynamically generates a data acquisition whitelist that complies with the AUTOSAR standard and synchronizes the whitelist to the MCU through the SPI bus. The SecOC mechanism is used to verify the integrity, and the double buffering mechanism ensures that the MCU obtains the latest acquisition strategy in real time. Among them, AUTOSAR (AUTomotive Open System ARchitecture) is an open standard automotive software architecture that aims to achieve hardware and software separation and standardization between different vehicle electronic control units (ECUs).

[0035] Next, the MCU filters controller messages from multimodal sensors (such as front-view and surround-view cameras and millimeter-wave radar) based on a whitelist, retaining only the data on the whitelist. Cyclic redundancy check (CRC) and RollingCounter tamper-proofing are performed on the retained data to ensure data integrity. Data that passes verification is synchronized to the MPU via the SPI bus using a custom protocol, forming a valid data stream.

[0036] Finally, after receiving valid data synchronized by the MCU, the MPU first stores it locally and then processes it according to ASIL level (D / B / QM). Specifically, if the valid data is high-priority real-time data (ASIL-D), such as emergency braking or lane departure signals, it is immediately reported using event triggering, and transmitted to the vehicle cloud platform via the CAN bus or 5G network upon completion of data collection. If the valid data is low-priority data (ASIL-B), such as vehicle status information, it is intelligently delayed based on network bandwidth utilization, and the upload timing is dynamically adjusted via the TCP protocol. If the data is non-real-time historical data (QM), it is packaged using the LZMA (Lempel-Ziv-Markov chain algorithm) high compression algorithm and uploaded in segments via the dual-channel TCP protocol, supporting scheduled active upload or cloud-triggered passive upload. Among them, "QM level" (Quality Management level) refers to the classification of systems or components that are considered to have sufficiently low risk that their safety can be ensured through conventional quality management system measures alone.

[0037] In addition, after receiving the hierarchical data, the car cloud platform uses the LZ4 compression protocol for streaming decompression, combines pre-trained models (such as scene recognition engines) to extract features and perform business analysis (such as range extender dynamic control). When a key signal is missing or a model iteration is detected, the cloud triggers the historical data retransmission mechanism and sends an incremental data request instruction to the MPU. After the MPU responds to the request, it uploads the LZMA compressed data packet of the specified time period to the cloud, merges multiple versions of data through data lake technology, and starts offline batch processing jobs for compensation analysis to form a closed-loop link. Among them, LZ4 is a fast lossless compression algorithm that aims to provide extremely high compression and decompression speeds while maintaining a reasonable compression ratio.

[0038] It can be understood that this embodiment achieves efficient utilization of terminal device computing power, optimized allocation of network resources and improved reliability of cloud analysis through the signal transmission sequence of "configuration issuance → whitelist synchronization → data filtering → hierarchical transmission → cloud analysis → abnormality compensation", meeting the precise control needs in closed scenarios.

[0039] Figure 3 This is a flowchart of a method for hierarchical processing of in-vehicle data executed by the cloud, shown as an exemplary embodiment of the present application.

[0040] like Figure 3 As shown, in an exemplary embodiment, the vehicle data hierarchical processing method includes at least steps S310 to S340, which are described in detail as follows:

[0041] Step S310: Send a structured configuration file to the terminal device. The structured configuration file is generated based on the target service scenario and includes the signal identifier to be collected, data type, transmission trigger condition, data priority and compression rules.

[0042] In one embodiment of the present application, the generation of a structured configuration file includes: establishing data timeliness constraint rules including transmission delay, throughput and service quality level based on the business demand indicators of the target business scenario; constructing a data processing framework based on the data timeliness constraint rules, determining the original data fields and their precision parameters, and the original data fields cover vehicle control signal sets or independently collected signals; developing structured data definition specifications, and generating a structured configuration file that describes the physical identification of the data source, signal collection cycle and event trigger conditions.

[0043] In one embodiment of the present application, after obtaining the business scenario, it is necessary to further decompose its requirements and generate a corresponding structured configuration file. The requirements decomposition steps include requirements analysis, algorithm modeling, and data mapping. Among them, the requirements analysis is to establish a data timeliness matrix based on the business SLA (Service Level Agreement) indicators (including differentiated requirements such as real-time alarms and batch analysis), and clarify the technical requirements of each scenario for latency, throughput and QoS (Quality of Service) level; the algorithm modeling is to adopt the service-oriented architecture (SOA) design principle to build an algorithm framework including feature engineering modules, stream processing engines and model reasoning components, and simultaneously define the required raw data fields and their sampling accuracy; the data mapping is to develop a data dictionary based on the ISO 24089 standard, generate an XML / JSON format acquisition structured configuration file, and structurally describe the data attributes of the data source such as CAN ID (Controller Area Network Identifier), signal period, trigger conditions, etc.

[0044] In a specific embodiment of the present application, in the business scenario of driver risk profiling, the car cloud platform first carries out data demand decomposition. Based on the business service level agreement (SLA) indicators, the platform clearly defines the data timeliness requirements, for example, real-time alarms must complete data transmission within 100ms, and batch analysis allows a delay of 10s. Subsequently, the platform defines the raw data fields to be collected through algorithm modeling, including CAN signals such as steering wheel angle and pedal depth, as well as independent signals such as camera image metadata, and specifies their sampling accuracy (such as steering wheel angle accuracy of 0.1° and sampling frequency of 100Hz). Finally, the platform constructs a data dictionary based on the ISO 24089 standard, structuring parameters such as signal identification (such as CAN ID 0x18F1E300), data type (CAN data or independent signal), acquisition frequency (adjustable from 10ms to 10s), transmission trigger conditions (such as event-driven or network-aware) and data priority (ASIL-D, ASIL-B or QM level) into a structured configuration file in XML / JSON format. This file is sent to the terminal device via an HTTPS encrypted channel to ensure the security of the transmission process.

[0045] It is understood that in the above embodiment, the generation of structured configuration files through demand decomposition improves data processing efficiency and accuracy, while ensuring strict data timeliness requirements. The adoption of a service-oriented architecture enhances the adaptability and scalability of the algorithm framework, and data management is standardized according to ISO standards, facilitating system compatibility and maintenance. Furthermore, the use of HTTPS encrypted transmission ensures data security, overall improving business processing capabilities, system reliability, and service quality.

[0046] Step S320: receiving data collected by the terminal device. After the first processor in the terminal device parses the structured configuration file to generate a collection whitelist, the data is filtered and verified by the second controller according to the collection whitelist before being uploaded.

[0047] In one embodiment of the present application, the car cloud platform receives the collected data fed back by the terminal device. The process starts with the first processor of the terminal device obtaining a structured configuration file from the car cloud platform. The first processor parses the structured configuration file, generates a data collection whitelist containing parameters such as collection signal, frequency, accuracy, etc., and synchronizes the whitelist to the second controller of the terminal device through the SPI bus. The second controller filters the received controller message according to the whitelist, retains only the data that meets the whitelist rules, and performs cyclic redundancy check (CRC) and RollingCounter anti-tampering verification before transmission to ensure data integrity and security. The valid data that passes the verification is uploaded to the first processor by the second controller, which classifies and compresses it according to priority, and then uploads it to the car cloud platform in batches or in real time through the communication network. After receiving the above-mentioned collected data, the car cloud platform decompresses, restores and analyzes it according to business needs to complete the data closed-loop processing process.

[0048] In a specific implementation of the present application, the car cloud platform receives the collected data fed back by the terminal device by establishing a secure communication channel. During the data transmission process, the first processor (MPU) in the terminal device generates a collection whitelist based on the structured configuration file issued by the cloud, and synchronizes the whitelist to the second controller (MCU). After the MCU filters and verifies the integrity of the original controller message according to the whitelist, it uploads the valid data to the car cloud platform. The specific receiving process is as follows: The car cloud platform receives high-priority real-time data (such as emergency braking events) through the MQTT protocol, and receives delayed data and non-real-time historical data based on the HTTPS / TLS encrypted channel. All uploaded data is integrity checked through the SecOC mechanism to ensure that the data has not been tampered with. For real-time data, the car cloud platform uses the LZ4 streaming decompression algorithm to restore the signal instantly; for delayed data, it uses the LZMA high compression algorithm to decompress the data in batches, and reassembles the fragmented data packets according to the timestamp.

[0049] In step S330, the received data is divided into first data, second data, and third data in order of priority from high to low, and hierarchically processed according to the grading strategy, wherein the grading strategy corresponding to the first data includes real-time triggering, decompression, and business analysis; the grading strategy corresponding to the second data includes starting decompression analysis when network resources meet preset conditions; the grading strategy corresponding to the third data includes performing offline analysis on historical data after decompression.

[0050] In one embodiment of the present application, the hierarchical processing includes: setting a network bandwidth utilization threshold interval, triggering decompression analysis of the second priority data when the bandwidth utilization is monitored in real time to be lower than the lower threshold; compressing the third priority historical data, and generating a transmission file package according to the preset fragmentation rules; performing batch transmission based on a reliable transmission channel, and dynamically adjusting the fragment size and transmission rate based on network status feedback.

[0051] In a specific embodiment of this application, the car-to-cloud platform performs hierarchical processing on received data and dynamically allocates resources based on data priority and network status to ensure the real-time performance of critical services and the efficiency of non-critical tasks. Therefore, the data is divided into three different priorities, as follows:

[0052] For priority data—ASIL-D high-real-time signals (such as emergency braking events)—the car-to-cloud platform immediately decompresses the data upon receipt, eliminating the need to wait for network resources to become available. The decompressed data is directly fed into real-time business systems (such as the risk warning module) for immediate decision-making (e.g., triggering alerts, adjusting driving strategies), and is simultaneously written to a time series database, retaining the last hour's worth of data for rapid retrospective analysis.

[0053] For second-priority data, specifically ASIL-B periodic status signals (such as ambient temperature and camera timestamps), decompression analysis is initiated when network bandwidth utilization falls below a preset threshold (e.g., 30%). A high-compression algorithm is used to batch decompress the fragmented data and reassemble the complete data packets by timestamp. The decompressed data enters a batch processing queue and is distributed via a message queue to feature extraction and model training tasks, supporting non-real-time business needs (such as driver status assessment).

[0054] For the third-priority data, that is, QM-level historical data (such as long-term behavior records), after efficient compression, transmission file packages are generated according to preset rules (such as each piece ≤ 1MB) to reduce transmission overhead. Batch uploads are performed through a multi-channel transmission protocol, and the shard size (such as reducing it to 512KB when the network jitters) and transmission rate are dynamically adjusted to prioritize the bandwidth of high-priority data. The decompressed data is stored in a distributed storage system. After the versions are merged using unified data lake technology, offline batch processing jobs are started to output long-term trend analysis results (such as driving behavior pattern mining).

[0055] It is understandable that based on the above-mentioned hierarchical processing strategy, the car-cloud platform achieves real-time response to high-priority data, resource-sensitive processing of medium-priority data, and efficient offline analysis of low-priority data, taking into account business continuity and resource optimization, and providing reliable support for data-driven decision-making of intelligent connected vehicles.

[0056] Step S340: When any data anomaly is detected during analysis, a historical data supplement request is sent to the terminal device and a compensation analysis is performed.

[0057] In one embodiment of the present application, when the vehicle cloud platform detects a preset abnormal condition in the data stream (such as the absence of a key signal or the model prediction deviation exceeds the threshold), it will initiate a historical data supplement request to the terminal device and perform compensation analysis. The specific process is as follows: First, when a data anomaly is identified (such as the steering wheel angle signal is not reported for 3 consecutive frames), the vehicle cloud platform generates an incremental data request instruction according to the anomaly type, clearly specifies the time period to be supplemented (such as 2025-06-11T15:00:00Z to 2025-06-11T15:05:00Z) and the target signal (such as SteeringWheelAngle), and sends it to the terminal device through an HTTPS encrypted channel. Then, the terminal device extracts the historical data packet of the specified time period from the local storage, and uploads it to the cloud after compression. After receiving the data, the vehicle cloud platform verifies the integrity of the data, reorganizes the fragments in timestamp order, and merges the supplemented data with the existing data lake through Delta Lake technology to generate a complete historical data set. Finally, the car-cloud platform initiates an offline batch processing job to perform feature extraction and model retraining on the merged data, correcting prediction biases caused by missing data. The analysis results are output as structured reports to business systems such as driver behavior assessment and vehicle fault diagnosis. The prediction model for the terminal device is also updated, forming a closed-loop process of anomaly detection, retransmission, analysis, and correction. Delta Lake is an open source storage layer designed to bring reliability, security, and performance to the data lake, making large-scale data processing easier and more efficient.

[0058] It can be understood that through the method of the above embodiment, the vehicle cloud platform can quickly locate abnormal time periods and trigger supplementary transmission, use offline analysis to make up for the lack of real-time data, and ensure the integrity of business scenarios and decision reliability.

[0059] Figure 4 This is a flowchart of a vehicle data classification processing method executed by a terminal device, which is shown as an exemplary embodiment of the present application.

[0060] like Figure 4As shown, in an exemplary embodiment, the vehicle data hierarchical processing method includes at least steps S410 to S450, which are described in detail as follows:

[0061] Step S410: Receive a structured configuration file sent from the cloud. The structured configuration file is generated based on the target business scenario and includes the signal identifier to be collected, data type, transmission trigger condition, data priority and compression rules.

[0062] In one embodiment of the present application, the cloud generates a structured configuration file based on business needs (such as driver risk warning or vehicle health monitoring), and the structured configuration file includes relevant information such as signal identification, data type, transmission trigger conditions, data priority and compression rules. The signal identifier to be collected specifies the CAN signal to be collected (e.g., SteeringWheelAngle, BrakePedalPosition), its unit, and description. The data type defines the signal's data format (e.g., 16-bit integer, 32-bit floating point) and sampling frequency (e.g., 50Hz). The transmission trigger condition sets whether the signal is event-driven (e.g., AEB trigger), periodic (reporting every minute), or mixed mode (event priority + periodic supplement). The data priority indicates the priority level based on ASIL level (e.g., ASIL-D for emergency signals, ASIL-B for status signals, and QM for logging). The compression rule specifies the compression algorithm (e.g., LZ4 for real-time data, LZMA for historical data) and the segment size (e.g., 1MB / segment). An AEB (Automatic Emergency Braking) trigger refers to the system's action of automatically applying the brakes to avoid or mitigate a collision when the vehicle detects a potential collision ahead.

[0063] The structured configuration file is then sent to the terminal device through an HTTPS / TLS encrypted channel, accompanied by a SecOC dynamic signature to ensure that the transmission process is tamper-proof, so that after the terminal device receives the configuration, it can verify the identity of the sender through whitelist verification.

[0064] It can be understood that based on the method of the above embodiment, the terminal device can accurately receive and execute the structured configuration sent from the cloud to achieve dynamic adaptation of data collection strategies and business scenarios, thereby ensuring the security of configuration transmission and execution consistency.

[0065] In step S420 , the first processor of the terminal device parses the structured configuration file to generate a data collection whitelist, where the data collection whitelist includes signal collection frequency and accuracy parameters.

[0066] In one embodiment of the present application, a structured configuration file is parsed to generate a data acquisition whitelist, including: parsing the signal acquisition frequency parameters defined in the structured configuration file to generate an acquisition whitelist data structure containing an adjustable acquisition frequency range; synchronizing the acquisition whitelist to a second controller that performs message filtering through a preset bus communication protocol, and executing an acquisition whitelist integrity protection mechanism during the synchronization process; establishing a double cache strategy to store the old and new versions of the acquisition whitelist to ensure that the second controller obtains the latest acquisition strategy in real time; and dynamically adjusting the signal acquisition period according to the acquisition frequency parameters updated in the structured configuration file.

[0067] In a specific embodiment of the present application, the first processor (MPU) of the terminal device generates a data collection whitelist by parsing the structured configuration file sent from the cloud, and synchronizes the whitelist to the second controller (MCU) that performs message filtering. The specific steps are as follows: The MPU first parses the structured configuration file sent from the cloud, extracts key parameters to construct a data collection whitelist, and its keyword parameters include signal identification, acquisition frequency parameters, and precision parameters. Among them, the signal identification is used to determine the name of the CAN signal to be collected (such as SteeringWheelAngle, BrakePedalPosition) and its description and unit; the acquisition frequency parameter is used to define the minimum sampling frequency (such as 50Hz) and the maximum adjustable frequency (such as 200Hz) of the signal according to business requirements, forming an adjustable frequency range (such as [50,200]Hz); the precision parameter is used to clarify the quantization accuracy of the signal (such as 16-bit integer, 32-bit floating point) and the valid data range (such as the steering wheel angle range is [-540,540]°). Then, after the parsing is completed, the MPU constructs the above parameters into structured whitelist data as the basis for subsequent collection strategies.

[0068] Step S430: Filter the controller messages generated by the second controller of the terminal device based on the data collection whitelist, and perform integrity verification on the data that meets the conditions.

[0069] In one embodiment of the present application, based on the collection whitelist filtering controller message, integrity verification is performed on the qualified data, including: receiving the original message sent by the second controller, the original message is received through the controller local area network and the interface of the customized vehicle communication protocol; performing a cyclic redundancy check on the message data in the collection whitelist, and determining the data that passes the cyclic redundancy check as the first-level verification data; performing a counter anti-tampering verification on the first-level verification data, and determining the data that passes the counter anti-tampering verification as the second-level verification data; synchronizing the second-level verification data to the first processor in real time for subsequent hierarchical transmission processing.

[0070] In a specific embodiment of the present application, after generating the controller message, the second controller (MCU) of the terminal device filters and verifies the integrity of the received original message based on the collection whitelist issued by the first processor (MPU) to ensure data compliance and security. The specific process is as follows:

[0071] First, the MCU receives raw messages via the Controller Area Network (CAN bus) or a customized in-vehicle communication protocol (such as an enterprise-defined protocol). This includes capturing standardized messages (such as SteeringWheelAngle and BrakePedalPosition) from the in-vehicle ECU (Electronic Control Unit) through the physical CAN controller; and parsing messages encapsulated by the enterprise-defined protocol (such as extended fields based on JT / T 808 or GB / T 32960.3) to extract business-critical data. The received raw messages contain timestamps, signal identifiers (IDs), and raw values, providing the data foundation for subsequent filtering and verification.

[0072] The MCU then filters the original message based on the acquisition whitelist (including signal identification, frequency range, and accuracy parameters) issued by the MPU. This includes retaining signals defined in the whitelist (such as SteeringWheelAngle) and discarding unauthorized signals (such as EngineRPM); verifying that the message conforms to the preset communication protocol (such as the CAN FD frame format or the field length of a custom protocol) to exclude illegally encapsulated data; and comparing the actual sampling frequency of the message with the frequency range defined in the whitelist (such as 50Hz to 200Hz). If the frequency exceeds the range, it is marked as abnormal data and logged.

[0073] Next, a two-stage integrity verification is performed on the whitelisted packets to ensure data has not been tampered with and transmission continuity. The first stage is a cyclic redundancy check (CRC-CCITT) algorithm. The MCU calculates a checksum based on the data frame content (including signal values ​​and metadata). The receiving end extracts the data content based on the message length field and compares the calculated result with the CRC code appended to the end of the message. If there is a mismatch, the packet is discarded and an alarm is triggered to prevent transmission errors or malicious tampering. The second stage is a counter-based tamper-proof verification. Each packet (i.e., the first-level checksum data) is appended with an incrementing sequence number (RollingCounter). The MCU maintains a local counter and compares it with the received value. If the current sequence number is continuous with the expected value (e.g., ExpectedSN = LastSN + 1), the packet is considered valid. If the sequence number jumps (e.g., receiving SN = 13 when LastSN = 10), it is flagged as a packet loss or injection attack. If the sequence number rolls back (e.g., receiving SN = 8 when LastSN = 10), it is considered a replay attack and the packet is discarded. Furthermore, timestamp verification can be combined to further prevent packet forgery and ensure data authenticity.

[0074] Finally, the data packets that pass the integrity verification (i.e., the secondary verification data) are synchronized to the MPU for subsequent hierarchical transmission processing.

[0075] It can be understood that through the method proposed in this embodiment, the MCU realizes precise message filtering and double integrity verification (CRC+counter) based on the collection whitelist, ensuring the legality and security of the transmitted data, while providing reliable input for the hierarchical processing of the MPU, meeting the stringent requirements for data real-time and security in the Internet of Vehicles scenario.

[0076] Step S440, perform differentiated transmission according to data priority: first priority data is triggered and reported to the cloud in real time; second priority data is reported with a delay when network resources meet preset conditions; third priority historical data is compressed and uploaded in batches.

[0077] In one embodiment of the present application, the terminal device implements a differentiated transmission strategy based on data priority (first priority, second priority, third priority), combining 5G network characteristics, data compression technology, and dynamic resource scheduling to achieve efficient and reliable data upload. The specific process is as follows:

[0078] First, the first priority data is processed. This type of data needs to be triggered and reported to the cloud in real time. It is suitable for high-time-efficiency business scenarios, such as emergency braking events or traffic light status monitoring. When a preset event is detected (such as AEB activation), the second controller (MCU) immediately generates a high-priority data packet (such as BrakePedalPosition, CollisionWarning) containing a timestamp and RollingCounter sequence number, and uploads it in real time through the URLLC (Ultra-Reliable Low-Latency Communication) channel of the 5G network to ensure end-to-end latency is less than 10ms. If the current network bandwidth is insufficient, the system will prioritize resources to ensure that critical data is transmitted first. For example, when a vehicle detects an emergency braking of a vehicle in front while driving at high speed, the MCU generates a CollisionWarning data packet and uploads it to the cloud within 10ms through the 5G URLLC channel, triggering the warning system and broadcasting it to surrounding vehicles to avoid chain accidents.

[0079] For the second-priority data, it is suitable for scenarios that are not real-time but require periodic updates (such as vehicle status monitoring). The MCU generates data packets (such as EngineRPM, BatteryVoltage) at a preset period (such as every minute) and attaches a priority tag. The first processor (MPU) continuously evaluates the network status (such as bandwidth, latency) and triggers upload only when the network meets the preset conditions (such as bandwidth ≥ 5Mbps and latency < 50ms). If the network load is high, it will be delayed until the next cycle (such as 1 minute later) before attempting to transmit again. For example, when a vehicle is driving on a city road, the MCU collects EngineRPM data every minute. When the network bandwidth is 8Mbps and the latency is 30ms, the MPU immediately triggers upload; if the bandwidth drops to 2Mbps, it will be delayed until the next cycle transmission to avoid preempting the first-priority resources.

[0080] The third priority data mainly processes historical data with low timeliness and high storage volume (such as trajectory playback logs). The MCU archives such locally stored data (such as HistoricalLocation, DiagnosticLogs) according to time windows and compresses it using the LZ4 algorithm (the compression rate can reach 40%-60%). The compressed data is uploaded in 1MB segments and transmitted in batches during network idle periods (such as 02:00-05:00 at night). Its priority is lower than the first two types of data. If the upload is interrupted, the MCU records the uploaded segment index and continues uploading from the breakpoint at the next startup. For example, a vehicle generates 1GB of historical trajectory data in a day. The MCU compresses it to 400MB using LZ4 and uploads it in 1MB segments. If a segment is lost due to network interruption, it will be uploaded again at 02:00 the next day to ensure data integrity.

[0081] In addition, to deal with priority conflicts, this method also designs a preemption mechanism and a dynamic adjustment strategy. The first-priority data can forcibly interrupt the transmission of the second and third priorities. If the first-priority data is backlogged, the MPU temporarily reduces the upload frequency of the second priority (such as extending the EngineRPM cycle from 1 minute to 5 minutes). For the third-priority data that has not been uploaded for a long time, the MCU sends an alarm to the cloud and requests a temporary increase in its priority. In addition, the dynamic weight adjustment strategy further optimizes resource allocation, ensuring the real-time performance of critical services while taking into account the efficient transmission of non-critical data.

[0082] It can be understood that, based on the differentiated transmission strategy proposed in this embodiment, the terminal device achieves real-time response of critical data and efficient use of non-critical data under limited network resources.

[0083] Step S450 , in response to the historical data supplement request initiated by the cloud, upload historical data of a specified period that matches the historical data supplement request.

[0084] In one embodiment of the present application, after receiving a historical data supplement request initiated by the cloud, the terminal device first parses the request content to extract the time window, data type, and priority requirements. For example, the cloud may specify that the data to be supplemented is 2025-03-01

[0085] The vehicle trajectory log from 00:00:00 to 2025-03-05 23:59:59 is requested to increase the priority to the second priority.

[0086] After the parsing is completed, the local storage module is called to locate the matching historical data files (such as HistoricalLocation_20250301.lz4 to HistoricalLocation_20250305.lz4) according to the time range and data type, and decompress them one by one to restore the original data structure.

[0087] To ensure data integrity, a cyclic redundancy check (CRC) and serial number continuity verification (RollingCounter) can also be performed on the decompressed data to ensure that the data is not damaged during storage or decompression. Subsequently, metadata (such as request identifier and upload timestamp) is attached, and the complete data set is processed in 1MB segments to support breakpoint resumption. If the cloud specifies a high priority, the requested data is uploaded first through a preemptive scheduling mechanism, and low-priority tasks are suspended; if network resources are insufficient, the upload is delayed until an idle period (such as night). In addition, during the upload process, if a segment fails due to network interruption, the failure index is recorded and the transmission is continued from the breakpoint after the network is restored, and a maximum of 3 retries are made. Finally, after the upload is completed, the results are fed back to the cloud, including successful or failed segment information, to ensure data consistency and traceability.

[0088] It can be understood that the method based on the above embodiment achieves efficient and reliable historical data supplementation through dynamic priority adjustment, segmented upload and exception handling mechanism, meeting the cloud's precise demand for historical data backtracking.

[0089] Finally, it's important to emphasize that the "in-vehicle data hierarchical processing" method proposed in this application significantly improves the efficiency and security of in-vehicle data processing through technologies such as data classification and grading, dynamic priority scheduling, and encrypted transmission. Its core advantages include: dynamic priority management optimizes resource utilization; data compression and breakpoint resume reduce storage and transmission costs; and verification and tamper-proofing ensure data integrity. Ultimately, within limited computing power and network conditions, it achieves a balance between real-time performance, security, and cost, providing reliable technical support for data governance in intelligent connected vehicles.

[0090] Figure 5 4 is a block diagram of an in-vehicle data hierarchical processing system shown in an exemplary embodiment of the present application.

[0091] This application also proposes a vehicle-mounted data hierarchical processing system, such as Figure 5 The system shown includes a cloud 510 and a terminal device 520 .

[0092] The cloud 510 includes a configuration generation module 511, a hierarchical processing engine 512, and an anomaly compensation module 513; the configuration generation module 511 is used to generate a structured configuration file based on the target business scenario, and the structured configuration file includes the signal identifier to be collected, the data type, the transmission trigger condition, the data priority and the compression rule; the hierarchical processing engine 512 is configured to perform hierarchical processing according to the hierarchical strategy, wherein the hierarchical strategy corresponding to the first data includes real-time triggering, decompression and business analysis; the hierarchical strategy corresponding to the second data includes starting decompression analysis when the network resources meet the preset conditions; the hierarchical strategy corresponding to the third data includes performing offline analysis of historical data after decompression; the anomaly compensation module 513 is used to initiate a historical data supplement request to the terminal device when a data anomaly is detected, and perform compensation analysis on the supplemented data;

[0093] The terminal device 520 includes a first processor 521, a second controller 522, and a communication interface module 523; the first processor 521 is configured to parse the structured configuration file sent from the cloud and generate an acquisition whitelist containing signal acquisition frequency and accuracy parameters; perform differentiated transmission control according to data priority: report first priority data in real time, report second priority data with a delay when the network conditions are met, and upload third priority historical data in batches after compression; the second controller 522 is used to filter the generated controller message based on the acquisition whitelist, perform cyclic redundancy check and counter anti-tampering verification on the filtered data, and synchronize the verified data stream to the first processor; the communication interface module 523 is used to respond to historical data supplement requests from the cloud and upload historical data packets for a specified time period.

[0094] It should be noted that the hierarchical vehicle data processing system provided in the above-mentioned embodiments and the hierarchical vehicle data processing method provided in the above-mentioned embodiments are based on the same concept. The specific manner in which each module and unit performs operations has been described in detail in the method embodiments and will not be repeated here. In actual applications, the hierarchical vehicle data processing device provided in the above-mentioned embodiments can, as needed, allocate the above-mentioned functions to different functional modules, i.e., divide the internal structure of the device into different functional modules to perform all or part of the functions described above. This is not a limitation herein.

[0095] An embodiment of the present application also provides an electronic device, comprising: one or more processors; a storage device for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the electronic device implements the vehicle data hierarchical processing method provided in the above-mentioned embodiments.

[0096] Figure 6The following is a schematic diagram showing the structure of a computer system suitable for implementing an electronic device according to an embodiment of the present application. Figure 6 The computer system 600 of the electronic device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0097] like Figure 6 As shown, the computer system 600 includes a central processing unit (CPU) 601, which can perform various appropriate actions and processes according to the program stored in the read-only memory (ROM) 602 or the program loaded from the storage part 608 into the random access memory (RAM) 603, such as executing the method described in the above embodiment. Various programs and data required for system operation are also stored in the RAM 603. The CPU 601, ROM 602 and RAM 603 are connected to each other via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0098] The following components are connected to the I / O interface 605: an input section 606 including a keyboard, a mouse, and the like; an output section 607 including devices such as a cathode ray tube (CRT), a liquid crystal display (LCD), and a speaker; a storage section 608 including a hard disk; and a communication section 609 including a network interface card such as a LAN (Local Area Network) card or a modem. The communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to the I / O interface 605 as needed. Removable media 611, such as a magnetic disk, an optical disk, a magneto-optical disk, or a semiconductor memory, is installed in the drive 610 as needed, so that computer programs read therefrom can be installed into the storage section 608 as needed.

[0099] In particular, according to an embodiment of the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, an embodiment of the present application includes a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a computer program for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via the communication section 609, and / or installed from a removable medium 611. When the computer program is executed by the central processing unit (CPU) 601, the various functions defined in the system of the present application are executed.

[0100] It should be noted that the computer-readable medium shown in the embodiments of the present application can be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable storage medium can be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of computer-readable storage media can include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), a flash memory, an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, which carries a computer-readable computer program. This propagated data signal can take a variety of forms, including but not limited to an electromagnetic signal, an optical signal, or any suitable combination of the above. A computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium that can transmit, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. A computer program embodied on a computer-readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, or any suitable combination thereof.

[0101] The flowcharts and block diagrams in the accompanying drawings illustrate the possible implementation architecture, functions and operations of the systems, methods and computer program products according to various embodiments of the present application. Among them, each box in the flowchart or block diagram can represent a module, program segment, or part of the code, and the above-mentioned module, program segment, or part of the code contains one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in an order different from that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flowchart, and the combination of boxes in the block diagram or flowchart, can be implemented with a dedicated hardware-based system that performs the specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0102] The units involved in the embodiments described in this application may be implemented by software or hardware, and the units described may also be set in a processor. In some cases, the names of these units do not constitute limitations on the units themselves.

[0103] Another aspect of the present application provides a computer-readable storage medium having a computer program stored thereon. When executed by a computer processor, the computer program causes the computer to perform the aforementioned method for hierarchical processing of in-vehicle data. The computer-readable storage medium may be included in the electronic device described in the above embodiments, or may exist independently and not be incorporated into the electronic device.

[0104] Another aspect of the present application provides a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the vehicle data hierarchical processing method provided in each of the above embodiments.

[0105] The above embodiments are merely illustrative of the principles and effects of this application and are not intended to limit this application. Anyone skilled in the art may modify or alter the above embodiments without departing from the spirit and scope of this application. Therefore, any equivalent modifications or alterations accomplished by a person of ordinary skill in the art without departing from the spirit and technical concepts disclosed in this application shall be covered by the claims of this application.

Claims

1. A method for hierarchical processing of vehicle-mounted data, characterized in that: The method is executed by the cloud and includes: Sending a structured configuration file to the terminal device, where the structured configuration file is generated based on the target service scenario and includes the signal identifier to be sampled, data type, transmission trigger conditions, data priority, and compression rules; receiving data collected by the terminal device, the data being filtered and verified by the second controller according to the collection whitelist after the first processor in the terminal device parses the structured configuration file to generate a collection whitelist; The received data is divided into first data, second data, and third data in descending order of priority, and hierarchically processed according to a hierarchical strategy, wherein the hierarchical strategy corresponding to the first data includes real-time triggering, decompression, and business analysis; the hierarchical strategy corresponding to the second data includes starting decompression and analysis when network resources meet preset conditions; and the hierarchical strategy corresponding to the third data includes performing offline analysis after decompression of historical data; When the analysis detects any data anomaly, a historical data supplement request is sent to the terminal device and a compensation analysis is performed.

2. The vehicle-mounted data hierarchical processing method according to claim 1, characterized in that: The generation of the structured configuration file includes: Based on the business demand indicators of the target business scenario, establish data timeliness constraint rules including transmission delay, throughput and service quality level; Building a data processing framework based on the data timeliness constraint rules to determine the original data fields and their precision parameters, wherein the original data fields include vehicle control signal sets or independent acquisition signals; Develop structured data definition specifications and generate structured configuration files that describe the physical identification of data sources, signal acquisition cycles, and event trigger conditions.

3. The vehicle-mounted data hierarchical processing method according to claim 1, characterized in that: The classification process includes: Obtain network bandwidth utilization threshold range, reliability transmission channel, and network status during data transmission; When the bandwidth utilization is detected to be lower than the lower threshold, decompression analysis of the second priority data is triggered; Compress the third priority historical data and generate a transmission file package according to the preset fragmentation rules; Batch transmission is performed based on the reliability transmission channel, and the fragment size and transmission rate are adjusted based on the network status feedback.

4. The vehicle-mounted data hierarchical processing method according to claim 1, characterized in that: Initiate historical data supplementation requests to terminal devices and perform compensation analysis, including: When a preset abnormal condition is detected in the received data, an incremental data request instruction is generated according to the abnormality type and sent to the terminal device; Receiving historical data packets of a specified period uploaded by a terminal device, and merging the historical data packets of the specified period; Start an offline batch processing job to perform compensation analysis on the merged data and output complete analysis results for the target business scenario.

5. A method for hierarchical processing of vehicle-mounted data, characterized in that: The method is executed by a terminal device and includes: Receive a structured configuration file sent from the cloud, where the structured configuration file is generated based on the target business scenario and includes the signal identifier to be collected, data type, transmission trigger conditions, data priority, and compression rules; The first processor of the terminal device parses the structured configuration file to generate a data collection whitelist, wherein the data collection whitelist includes signal collection frequency and accuracy parameters; Based on the data collection whitelist, the controller message generated by the second controller of the terminal device is filtered, and the integrity verification is performed on the data that meets the conditions; Differentiated transmission is performed based on the data priority: first-priority data is triggered and reported to the cloud in real time; second-priority data is reported with a delay when network resources meet preset conditions; third-priority historical data is compressed and uploaded in batches; In response to a historical data supplement request initiated by the cloud, historical data of a specified time period matching the historical data supplement request is uploaded.

6. The vehicle-mounted data hierarchical processing method according to claim 5, characterized in that: Parse the structured configuration file to generate a data collection whitelist, including: Parse the signal acquisition frequency parameters defined in the structured configuration file and generate an acquisition whitelist data structure containing an adjustable acquisition frequency range; Synchronize the collection whitelist to the second controller that performs message filtering through a preset bus communication protocol, and execute the collection whitelist integrity protection mechanism during the synchronization process; Establish a double buffer strategy to store the old and new versions of the acquisition whitelist to ensure that the second controller obtains the latest acquisition strategy in real time; The signal acquisition period is dynamically adjusted according to the acquisition frequency parameter updated in the structured configuration file.

7. The vehicle-mounted data hierarchical processing method according to claim 5, characterized in that: Filter controller messages based on the collection whitelist and perform integrity verification on qualified data, including: receiving an original message sent by the second controller, wherein the original message is received via an interface of a controller area network and a customized vehicle communication protocol; Performing a cyclic redundancy check on the message data in the collection whitelist, and determining the data that passes the cyclic redundancy check as the first-level verification data; Performing a counter tamper-proof verification on the primary verification data, and determining the data that passes the counter tamper-proof verification as the secondary verification data; The secondary verification data is synchronized in real time to the first processor for subsequent hierarchical transmission processing.

8. A vehicle-mounted data hierarchical processing system, characterized in that: The system includes a cloud and a terminal device, wherein: The cloud includes a configuration generation module, a hierarchical processing engine, and an anomaly compensation module; A configuration generation module is used to generate a structured configuration file based on the target business scenario, wherein the structured configuration file includes the signal identifier to be collected, the data type, the transmission trigger condition, the data priority and the compression rule; a hierarchical processing engine configured to perform hierarchical processing according to a hierarchical strategy, wherein the hierarchical strategy corresponding to the first data includes real-time triggering, decompression, and business analysis; the hierarchical strategy corresponding to the second data includes initiating decompression and analysis when network resources meet preset conditions; and the hierarchical strategy corresponding to the third data includes performing offline analysis after decompression of historical data; The anomaly compensation module is used to initiate a historical data supplement request to the terminal device when any data anomaly is detected, and perform compensation analysis on the supplemented data; The terminal device includes a first processor, a second controller, and a communication interface module; The first processor is configured to parse the structured configuration file sent from the cloud and generate a collection whitelist containing signal collection frequency and accuracy parameters; perform differentiated transmission control based on data priority: report first-priority data in real time, report second-priority data with a delay when network conditions are met, and upload third-priority historical data in batches after compression; a second controller, configured to filter the self-generated controller messages based on the collection whitelist, perform cyclic redundancy check and counter tamper-proof verification on the filtered data, and synchronize the verified data stream to the first processor; The communication interface module is used to respond to historical data supplement requests from the cloud and upload historical data packets for a specified period of time.

9. An electronic device, characterized in that: The electronic device comprises: one or more processors; A storage device for storing one or more programs, which, when executed by the one or more processors, enables the electronic device to implement the vehicle data hierarchical processing method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that A computer program is stored thereon, and when the computer program is executed by a processor of a computer, the computer is caused to execute the vehicle-mounted data classification processing method according to any one of claims 1 to 7.

Images