Vehicle-mounted data dynamic hierarchical compression and priority transmission method and computer storage medium

Abstract

This application relates to the field of vehicle diagnostic technology, and provides a method for dynamic hierarchical compression and prioritized transmission of in-vehicle data and a computer storage medium, including: acquiring multiple diagnostic datasets of a target vehicle; calculating the diagnostic value weight corresponding to each diagnostic dataset; obtaining a target compression level corresponding to each diagnostic dataset based on the diagnostic value weight; compressing each diagnostic dataset according to the target compression level to obtain each compressed diagnostic dataset; allocating each compressed diagnostic dataset to a corresponding target transmission queue according to the diagnostic value weight; and scheduling the transmission of each compressed diagnostic dataset to a cloud diagnostic platform according to the transmission execution order of each target transmission queue.

Description

Technical Field

[0001] This invention relates to the field of vehicle diagnostic technology, and in particular to a method for dynamic hierarchical compression and priority transmission of vehicle data, and a computer storage medium. Background Technology

[0002] As the electronic and electrical architecture of intelligent vehicles becomes increasingly complex, massive amounts of diagnostic data (including CAN bus signals, DTC logs, sensor timing streams, and snapshots) are generated daily during vehicle operation. In remote fault diagnosis scenarios, this data needs to be transmitted back to the cloud for analysis and processing.

[0003] However, limited by the bandwidth resources of in-vehicle cellular networks, existing technologies generally have shortcomings in the management of in-vehicle data uploads: First, the transmission strategy is crude; existing solutions mostly adopt a "full upload" mode without effectively identifying the data, resulting in a large amount of routine operating condition data with low diagnostic value (such as window and air conditioning status) continuously occupying and wasting expensive network bandwidth. Second, in the data processing stage, existing technologies typically use a uniform fixed compression algorithm (such as ZIP, LZ4) to compress all data indiscriminately, lacking a fidelity mechanism for highly sensitive fault signals (such as sudden changes in battery voltage and abnormal braking pressure), which is highly susceptible to... This leads to distortion of key feature data; secondly, the existing data transmission channels lack a differentiated scheduling mechanism, with emergency fault data (such as thermal runaway warnings) and ordinary logs being transmitted together with equal priority, causing high-risk events to fail to be delivered to the cloud first, resulting in severe delays in diagnostic response; finally, although some existing technologies have introduced data filtering based on preset rules, these rules are mostly static and fixed, and cannot be dynamically adjusted according to the real-time operating conditions of the vehicle. This fails to establish a quantifiable data diagnostic value assessment system, and it is also difficult to achieve synergistic optimization of compression strategies and transmission priorities, making it difficult to balance overall data transmission efficiency and diagnostic effectiveness. Summary of the Invention

[0004] Based on this, it is necessary to address the technical problems of existing technologies, such as bandwidth resource waste and distortion of key fault information caused by the "full upload" and "unified compression" strategies, as well as the delay in response to high-risk events and the inability of the system to adapt to dynamic changes in operating conditions due to the lack of priority scheduling mechanisms and dynamic diagnostic value assessment methods. Therefore, a method for dynamic hierarchical compression and priority transmission of vehicle data and a computer storage medium are proposed.

[0005] Firstly, a method for dynamic hierarchical compression and prioritized transmission of vehicle-mounted data is provided, applied to a vehicle-mounted terminal, the method comprising: Obtain multiple diagnostic datasets for the target vehicle; For each diagnostic dataset, the diagnostic value weight corresponding to each diagnostic dataset is calculated; Based on the diagnostic value weight corresponding to each diagnostic dataset, the target compression level corresponding to each diagnostic dataset is obtained; Based on the target compression level corresponding to each diagnostic dataset, each diagnostic dataset is compressed to obtain each compressed diagnostic dataset. Based on the diagnostic value weight corresponding to each diagnostic dataset, each compressed diagnostic dataset is assigned to a corresponding target transmission queue, wherein different target transmission queues correspond to different transmission execution orders; According to the transmission execution order corresponding to each of the target transmission queues, each compressed diagnostic dataset is scheduled for transmission to the cloud diagnostic platform, which is communicatively connected to the vehicle terminal.

[0006] Secondly, a device for dynamic hierarchical compression and priority transmission of vehicle-mounted data is provided, the device comprising: The acquisition unit is used to acquire multiple diagnostic datasets for the target vehicle. The processing unit is used to calculate the diagnostic value weight corresponding to each diagnostic dataset for each diagnostic dataset. The processing unit is further configured to obtain the target compression level corresponding to each diagnostic dataset based on the diagnostic value weight corresponding to each diagnostic dataset; The processing unit is further configured to compress each diagnostic dataset according to the target compression level corresponding to each diagnostic dataset, so as to obtain each compressed diagnostic dataset. The processing unit is further configured to allocate each compressed diagnostic dataset to a corresponding target transmission queue according to the diagnostic value weight corresponding to each diagnostic dataset, wherein different target transmission queues correspond to different transmission execution orders; The transmission unit is used to schedule the transmission of each compressed diagnostic dataset according to the transmission execution order corresponding to each target transmission queue, so as to transmit each compressed diagnostic dataset to the cloud diagnostic platform, which is communicatively connected to the vehicle terminal.

[0007] Thirdly, a vehicle-mounted data dynamic hierarchical compression and priority transmission system is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the steps of the above-described vehicle-mounted data dynamic hierarchical compression and priority transmission method.

[0008] Fourthly, a computer-readable storage medium is provided, the computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the above-described method for dynamic hierarchical compression and priority transmission of vehicle data.

[0009] In the embodiments implemented by the above-mentioned vehicle data dynamic hierarchical compression and priority transmission method, device, system, and computer storage medium, this embodiment calculates the corresponding diagnostic value weight for each diagnostic dataset of the target vehicle, determines the corresponding target compression level based on the weight, and then performs differentiated compression processing on the diagnostic dataset. This changes the processing method of using a uniform compression standard for all diagnostic data, allowing data with different diagnostic values ​​to obtain compression intensity commensurate with their importance. This effectively reduces the overall data processing and storage overhead while ensuring the processing effect of important diagnostic data. Simultaneously, each compressed diagnostic dataset is allocated to the corresponding target transmission team based on its diagnostic value weight. The compressed diagnostic dataset is scheduled for transmission according to the transmission execution order corresponding to different target transmission queues. This ensures that data with different diagnostic values ​​are transmitted to the cloud diagnostic platform in an order that matches their importance, avoiding the problem of unreasonable allocation of transmission resources caused by the indiscriminate transmission of various types of diagnostic data. Therefore, this embodiment uses the calculation results of diagnostic value weights to guide compression processing and transmission queue allocation and scheduling. This achieves that both compression strategies and transmission scheduling are carried out in synergy around diagnostic value weights, enabling the vehicle terminal to perform targeted compression and transmission processing based on the value differences of the diagnostic dataset. Under the condition of limited processing and transmission resources, the rationality and effectiveness of the overall processing and transmission of diagnostic data are improved. Attached Figure Description

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

[0011] in: Figure 1 This is a schematic diagram of the structure of an on-board data dynamic hierarchical compression and priority transmission system in one embodiment; Figure 2 This is a software architecture diagram of the vehicle data dynamic hierarchical compression and priority transmission system in this embodiment of the invention; Figure 3 This is a flowchart of a method for dynamic hierarchical compression and priority transmission of vehicle data in one embodiment; Figure 4 This is a structural block diagram of an on-board data dynamic hierarchical compression and priority transmission device in one embodiment; Detailed Implementation The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0012] Please see Figure 1 , Figure 1 This is a schematic diagram of a system for dynamic hierarchical compression and priority transmission of vehicle-mounted data. Figure 1 In the system, the vehicle-mounted data dynamic hierarchical compression and priority transmission system 10 includes an on-board terminal 20 and a cloud-based diagnostic platform 30.

[0013] Among them, the vehicle terminal 20 can be a vehicle T-Box, domain controller or vehicle gateway, etc.; the cloud diagnostic platform 30 can be a remote diagnostic cloud server, cloud AI analysis platform or central dispatch server, etc., and there is no single limitation here.

[0014] The vehicle-mounted terminal 20 includes at least one processor 201 and a memory 202.

[0015] The processor 201 is configured to support the vehicle data dynamic hierarchical compression and priority transmission system in performing the corresponding functions of the vehicle data dynamic hierarchical compression and priority transmission method applied to the vehicle terminal in the above method embodiment, such as performing the acquisition of diagnostic datasets, calculation of diagnostic value weights, determination of target compression level, execution of compression processing, allocation of target transmission queues, and control of scheduled transmission.

[0016] The processor 201 can be a central processing unit, a microcontroller, or a microprocessor. In an optional embodiment, when the vehicle terminal needs to process the weight calculation and compression of high-frequency waveform data in real time and has high requirements for computational latency, the processor 201 may further include a lookup table operation unit, a fixed-point number operation unit, or a hardware accelerator (such as an FPGA or DSP) to accelerate operations such as exponential decay calculation and frequency domain transformation of high-frequency waveform data in diagnostic value weighting, so as to ensure the real-time performance of weight calculation and compression processing. The processor may also be an application-specific integrated circuit (ASIC) or any combination thereof.

[0017] The memory 202 stores program code and various types of data required to support the dynamic hierarchical compression and priority transmission method for vehicle data. The memory 202 is coupled to the processor 201 and stores the program code for execution by the processor 201. It also stores data such as multiple diagnostic datasets, the first, second, and third feature parameters and diagnostic value weights corresponding to each diagnostic dataset, the mapping relationship between the target compression level and compression method, the mapping relationship between component key parameters and static base scores, the compressed data for each diagnostic dataset, data in the high-priority transmission queue, the medium-priority transmission queue, and the low-priority transmission queue, and parameter update packages sent from the cloud.

[0018] The memory 202 may include volatile memory, such as random access memory (RAM), for providing operating space and data cache for real-time calculation of diagnostic value weights and dynamic scheduling of each target transmission queue; the memory 202 may also include non-volatile memory, such as read-only memory, flash memory, hard disk or solid-state drive, for persistent storage of the vehicle configuration file, historical fault database and aggregated cold data in low-priority transmission queues; the memory 202 may also include a combination of the above types of memory.

[0019] The cloud-based diagnostic platform 30 also includes at least one processor and a memory (the internal structure is not shown in detail in the figure, but can be referenced from the vehicle terminal). The processor is configured to support the execution of the corresponding functions applied to the cloud-based diagnostic platform in the above method embodiments, such as receiving compressed diagnostic datasets uploaded by the vehicle terminal, performing AI analysis and fault pattern mining on the diagnostic data, generating new diagnostic value weight model parameters (such as updated component critical parameters or configurable coefficients), digitally signing parameter update packages, and issuing parameter update instructions to the vehicle terminal. The memory is used to store diagnostic data from multiple vehicles, fault pattern mining models, parameter update records from each vehicle terminal, and grayscale verification logs, etc.

[0020] In addition, the vehicle-mounted data dynamic hierarchical compression and priority transmission system also includes a communication component (not shown in the figure). The vehicle-mounted terminal 20 and the cloud diagnostic platform 30 establish a communication connection through a wireless communication network (such as a cellular network or Wi-Fi). The communication component is used to upload each compressed diagnostic dataset to the cloud diagnostic platform according to the transmission protocol corresponding to its target transmission queue (such as MQTT QoS2 or CoAP Confirmable for high-priority queues, MQTT QoS1 for medium-priority queues, and MQTT QoS0 or batch packet upload for low-priority queues), and to receive parameter update packets issued by the cloud diagnostic platform. The communication channel corresponding to this communication component can support batch caching and delayed retransmission mechanisms when the network link quality is poor.

[0021] At the software level, such as Figure 2 As shown, Figure 2 The diagram shows the software architecture of a vehicle-mounted data dynamic hierarchical compression and priority transmission system. The vehicle-mounted terminal 20 may include a weight calculation module 2100, a compression level determination module 2200, a compression processing module 2300, a queue allocation module 2400, and a scheduling transmission module 2500.

[0022] The weight calculation module 2100 is used to obtain the first feature parameter, the second feature parameter, and the third feature parameter of each diagnostic dataset, and to perform weighted calculation on the above feature parameters according to a preset weight evaluation algorithm to obtain the diagnostic value weight corresponding to each diagnostic dataset; the compression level determination module 2200 is used to determine the target compression level corresponding to each diagnostic dataset according to the diagnostic value weight; the compression processing module 2300 is used to determine whether each diagnostic dataset belongs to a preset discrete key field type, and to select the corresponding compression method to compress each diagnostic dataset in combination with the target compression level and the data type to which the dataset belongs, to obtain each compressed diagnostic dataset; the queue allocation module 2400 is used to allocate each compressed diagnostic dataset to the corresponding target transmission queue according to the diagnostic value weight corresponding to each diagnostic dataset, and to perform cross-queue migration when a change in diagnostic value weight is detected; the scheduling transmission module 2500 is used to schedule and transmit each compressed diagnostic dataset according to the transmission execution order of high-priority transmission queue, medium-priority transmission queue, and low-priority transmission queue, and to interrupt the scheduling and transmission of the medium-priority transmission queue and the low-priority transmission queue when there is data to be transmitted in the high-priority transmission queue.

[0023] Please see Figure 3 As shown, Figure 3 A flowchart illustrating a method for dynamic hierarchical compression and priority transmission of vehicle data provided in this embodiment of the invention, applied to a vehicle terminal, includes the following steps: S1: Obtain multiple diagnostic datasets for the target vehicle.

[0024] The target vehicle refers to an electric vehicle or intelligent connected vehicle that is currently undergoing remote fault diagnosis, and its various electronic control units (ECUs) continuously generate various electronic signals reflecting the vehicle's status during operation.

[0025] Among them, diagnostic datasets refer to single data records generated during vehicle operation that can reflect a specific state or event of the vehicle. Their specific forms can be CAN bus signals (such as vehicle speed and gear position), DTC logs (such as fault diagnosis codes and their activation status), sensor time streams (such as sampling sequences of battery cell voltage changes over time), or snapshot data (such as cross-sectional records of key parameters at the moment a fault occurs). Each diagnostic dataset usually corresponds to the acquisition results of a specific signal source on the vehicle (such as a signal reported by a certain ECU) at a certain moment or within a certain time period.

[0026] In practice, the vehicle terminal first checks each signal reported by the ECUs on the vehicle against a pre-configured signal monitoring list to ensure it falls within the scope of the list. This list records a list of signal sources that need to be continuously collected or triggered by events (e.g., ECU numbers and their corresponding signal names). By checking, the set of signal sources to be collected is determined, i.e., the list of diagnostic data sources to be collected. Subsequently, according to the standard vehicle bus communication protocol, the vehicle terminal reads the current raw values, fault diagnosis code activation status, or sensor sampling values ​​from the raw messages transmitted in real time on the vehicle bus (e.g., CAN bus) or the raw records generated locally by each ECU for each signal source in the set, and records the time of their generation. This yields multiple raw acquisition results with raw values ​​and generation times. Finally, according to a preset data structure, the vehicle terminal combines each raw acquisition result with its corresponding signal source identifier, generation time, and other information into an independent data record, thus obtaining multiple diagnostic datasets. Each diagnostic dataset corresponds to a specific signal record, providing the input basis for calculating the diagnostic value weight of each diagnostic dataset.

[0027] S2: Calculate the diagnostic value weight corresponding to each diagnostic dataset.

[0028] The diagnostic value weight is a scalar value used to measure the importance of a diagnostic dataset for remote fault diagnosis. The value ranges from 0 to 1, and the larger the value, the more important the diagnostic dataset is for diagnosis.

[0029] In one embodiment, the step of calculating the diagnostic value weight corresponding to each diagnostic dataset includes: obtaining a first feature parameter, a second feature parameter, and a third feature parameter for each diagnostic dataset; and performing a weighted calculation on the first feature parameter, the second feature parameter, and the third feature parameter according to a preset weight evaluation algorithm to obtain the diagnostic value weight corresponding to each diagnostic dataset.

[0030] The first feature parameter refers to a value used to reflect the degree of correlation between a certain diagnostic dataset and the current vehicle fault. Its value is also normalized to between 0 and 1, that is, the first feature parameter can be the fault correlation degree.

[0031] The second feature parameter refers to a value that reflects the criticality of a component belonging to a certain diagnostic dataset within the vehicle's safety architecture.

[0032] The third feature parameter refers to a value used to reflect the urgency of events associated with a certain diagnostic dataset in the time dimension. This value gradually decreases as time passes after the event occurs.

[0033] The preset weight evaluation algorithm refers to a pre-defined calculation rule used to sum the first feature parameter, the second feature parameter, and the third feature parameter according to their respective coefficients to obtain the diagnostic value weight.

[0034] Specifically, the formula corresponding to the preset weight evaluation algorithm is: W = α.F + β.C + γ.T; Wherein, W is the diagnostic value weight, with a value range of [0, 1]; F is the first characteristic parameter (fault correlation); C is the second characteristic parameter (component criticality); T is the third characteristic parameter (time sensitivity factor), and α, β, and γ are the configurable coefficients of the corresponding three characteristic parameters, satisfying α+β+γ=1. Their default values ​​are all 1 / 3, and they can be dynamically adjusted remotely by the cloud via OTA (over-the-air) technology to adapt to different diagnostic strategy requirements.

[0035] Specifically, after calculating the three feature parameters F, C, and T for each diagnostic dataset in sequence, the vehicle terminal reads the current weight coefficients α, β, and γ from the local configuration area. The processor of the vehicle terminal substitutes these three feature parameters and their corresponding weight coefficients into the preset weight evaluation algorithm formula, performs multiplication and addition operations, and outputs the final scalar result as the diagnostic value weight W of the diagnostic dataset.

[0036] For example, the vehicle terminal performs calculations on a diagnostic dataset of a "single cell voltage drop" signal reported by a BMS. The vehicle terminal detects that DTCU0123 (BMS communication loss) is currently active, and that "single cell voltage" is its associated signal, determining that the first feature parameter F=1. The vehicle terminal reads the vehicle configuration file and learns that the BMS is a high-safety-level component, mapping the output to the second feature parameter C=0.95. The vehicle terminal obtains that the event has just occurred, with a current time difference Δt=5 seconds, and uses the exponential decay function (λ=0.01) to calculate the third feature parameter T≈0.95. The vehicle terminal reads the default configuration coefficients α=1 / 3, β=1 / 3, γ=1 / 3, and substitutes them into the formula to calculate: W=(1 / 3)×1+(1 / 3)×0.95+(1 / 3)×0.95≈0.97. The vehicle terminal ultimately assigns a diagnostic value weight W of 0.97 to this dataset.

[0037] The mathematical formula for the exponential decay function is: T = e^(-λ·Δt); where T is the third feature parameter (time-sensitive factor), e is the natural constant (approximately equal to 2.71828), λ is the preset time decay coefficient (with a value of 0.01), and Δt is the time difference (in seconds) between the time of occurrence of the event associated with the diagnostic dataset and the current time.

[0038] As can be seen, in this embodiment, by substituting multi-dimensional feature parameters into a configurable linear weighted formula for fusion through the vehicle terminal, the comprehensive diagnostic value of each data point can be obtained scientifically and quantitatively. The entire calculation process is automatically completed in a closed loop on the vehicle terminal without cloud or manual intervention, and it supports flexible adjustment of weight coefficients through OTA, realizing dynamic optimization and expansion of the diagnostic strategy.

[0039] In one embodiment, obtaining the first feature parameter of each diagnostic dataset includes: determining whether the target vehicle currently has an activated fault diagnosis code; if an activated fault diagnosis code exists, determining whether each diagnostic dataset is a signal associated with the activated fault diagnosis code; if each diagnostic dataset is a signal associated with the activated fault diagnosis code, setting the first feature parameter of each diagnostic dataset to a preset maximum value; or, if no activated fault diagnosis code exists, or if each diagnostic dataset is not a signal associated with the activated fault diagnosis code, obtaining historical fault data, querying the frequency of occurrence of each diagnostic dataset under similar fault scenarios from the historical fault data; normalizing the frequency of occurrence to obtain a normalization result, the normalization result being the first feature parameter of each diagnostic dataset.

[0040] Among them, fault diagnosis codes are codes generated and reported by various electronic control units of the vehicle according to standard protocols when they detect operational abnormalities, and are used to identify specific fault types. Activated fault diagnosis codes refer to fault codes that are currently occurring and have not yet been cleared.

[0041] Historical fault data refers to statistical data stored locally on the vehicle terminal, which records the occurrence of various signals accompanying various faults over a period of time.

[0042] Among them, the associated signals refer to the signal sources in the "signal linkage map" stored and maintained locally on the vehicle terminal that have a direct physical causal relationship or strong coupling with a specific DTC. For example, the signals associated with the DTC "P0AFA (Power Battery Temperature Too High)" usually include "maximum battery cell temperature" and "battery module temperature".

[0043] In practice, the vehicle terminal first reads the local CAN bus network status, traverses each control domain, and determines whether the target vehicle currently has any activated fault diagnosis codes. If an activated fault diagnosis code exists, the vehicle terminal extracts the signal identifier of the diagnostic dataset and queries it in a locally preset signal linkage map to determine whether the diagnostic dataset is associated with the activated fault diagnosis code. Since the core data involved in the ongoing fault is crucial for diagnosis, if it is determined to be an associated signal, the vehicle terminal directly sets the first characteristic parameter of the diagnostic dataset to a preset maximum value (e.g., 1.0) to ensure the highest level of transmission fidelity.

[0044] The signal linkage map refers to a fault topology mapping table pre-stored locally on the vehicle terminal. Specifically, it is constructed as a mapping list or graph database structure of "Diagnostic Trouble Code (DTC) - Associated Signal Identifier - Associated Weight". In practice, the mapping relationships in the signal linkage map are generated by a cloud-based diagnostic platform using machine learning training based on massive historical fault diagnosis data, and then distributed to the vehicle terminal for local storage and updates via OTA (Over-The-Air) technology. For example, the signal linkage map stores the mapping record: "DTC U0123 (BMS communication loss) - Associated Signal ID: 0x1A2 (Single Cell Voltage Drop), 0x1A3 (Total Current Fluctuation) - Associated Weight: 1.0". When the vehicle terminal detects the activation of DTC U0123, it extracts the signal identifier of the current diagnostic dataset. If the signal identifier is 0x1A2, a matching mapping record is found in the signal linkage map, thus determining that the diagnostic dataset is an associated signal, and the corresponding associated weight can be directly read as the value of the first feature parameter F.

[0045] Specifically, if the vehicle terminal determines that no activated fault diagnosis code exists, or that the diagnostic dataset is not associated with an activated fault diagnosis code, it proceeds to the historical probability evaluation logic. The vehicle terminal retrieves pre-stored historical fault data from its local non-volatile memory and queries the frequency of occurrence of the diagnostic dataset under similar fault scenarios. For example, the vehicle terminal calculates the percentage of times the "leakage current sensor value" signal occurred when a "low insulation impedance" fault occurred in the past, based on locally recorded data. Subsequently, the vehicle terminal normalizes the queried frequency and outputs the normalized result as the first feature parameter of the diagnostic dataset.

[0046] For example, the vehicle terminal acquires two diagnostic datasets: a "unit temperature sequence" and a "door status sequence." The vehicle terminal detects an activated fault diagnosis code "P0AFA" on the current vehicle bus network. The vehicle terminal queries its local signal linkage graph and finds that "unit temperature" is marked as a strongly correlated signal with P0AFA. Therefore, the vehicle terminal directly sets the first feature parameter F of the "unit temperature sequence" to 1.0. Simultaneously, the vehicle terminal determines that "door status" is not a correlated signal with P0AFA. It then reads the local historical fault database and finds that the frequency of "door status" in all historical P0AFA-related (thermal runaway warning) fault scenarios is only 5 times out of 100 (i.e., 0.05). The vehicle terminal normalizes 0.05 and outputs the normalized result 0.05 as the first feature parameter of the "door status sequence."

[0047] As can be seen, this embodiment uses the dual dimensions of real-time DTC status of the vehicle terminal and local historical frequency for linkage judgment, which can accurately identify core data that are highly related to the current or potential faults and assign them the highest fault correlation. The entire feature extraction process is automatically executed on the vehicle terminal without cloud or manual intervention, and supports dynamic expansion to new vehicle models or new fault scenarios by updating the local configuration file.

[0048] In one embodiment, obtaining the second and third feature parameters of each diagnostic dataset includes: obtaining the vehicle model configuration file of the target vehicle; obtaining the component key parameters corresponding to the component to which each diagnostic dataset belongs in the vehicle model configuration file; mapping the component key parameters corresponding to the component to which each diagnostic dataset belongs to the corresponding static base score according to a preset mapping relationship between component key parameters and static base scores, wherein the static base score is the second feature parameter of each diagnostic dataset; obtaining the trigger time of the event corresponding to each diagnostic dataset; obtaining the time difference between the current time and the trigger time; calculating the time difference according to a preset exponential decay function to obtain a calculation result, wherein the calculation result is the third feature parameter of each diagnostic dataset.

[0049] Among them, the vehicle model configuration file refers to the configuration data file pre-stored by the vehicle terminal, which records the safety level information of each component of the current target vehicle model.

[0050] Among them, critical component parameters refer to the identification information marked for a certain component in the vehicle configuration file, which is used to characterize the safety level of the component in the vehicle safety architecture, such as the ASIL level based on ISO 26262 or a custom safety level code.

[0051] The static base score (second feature parameter) refers to the specific value obtained after converting the key parameters of the component according to the preset mapping relationship between the key parameters of the component and the static base score. This value is the second feature parameter. The trigger time refers to the actual time when an event associated with a certain diagnostic dataset (such as the first activation of a fault diagnosis code or the first occurrence of an abnormal operating condition) actually occurs.

[0052] The preset exponential decay function is a calculation function that takes the time difference between the triggering time and the current time as the independent variable, and the output decreases exponentially as the time difference increases. It is used to reflect the characteristic that the time urgency of an event will gradually decrease over time.

[0053] The calculation result represents the time-sensitive factor (i.e., the third characteristic parameter), which is a dynamic value used to measure the freshness or time decay of the diagnostic dataset, reflecting the diminishing impact of the proximity of the data generation time to the current moment on the diagnostic value.

[0054] The specific implementation of the mapping relationship between preset component key parameters and static base scores is to adopt an interval lookup table mapping mechanism. A component key level classification table is predefined, dividing each vehicle component into three key level intervals according to functional safety level, and establishing a mapping relationship between each level interval and the static base score. Specifically, the first key level (covering core components directly related to driving and high-voltage safety such as the braking system, battery management system (BMS), and steering system) corresponds to a static base score of 0.95; the second key level (covering power system components such as the motor and inverter) corresponds to a static base score of 0.85; and the third key level (covering non-critical comfort components such as the air conditioning system and infotainment system) corresponds to a static base score of 0.2. Specifically, after obtaining the critical parameters (such as component ID or predefined safety level code) of the component corresponding to the diagnostic dataset, the vehicle terminal inputs them into the mapping table to determine the matching interval. If the component belongs to the first critical level, the second feature parameter C=0.95 is directly output; if it belongs to the second critical level, C=0.85 is output; if it belongs to the third critical level, C=0.2 is output.

[0055] Specifically, the vehicle terminal reads the pre-written model configuration file of the target vehicle from local non-volatile memory. The vehicle terminal then iterates through this file to obtain the key parameters of each component corresponding to the component in the diagnostic dataset. Subsequently, the vehicle terminal calls a locally built-in mapping table between preset key parameters of components and static base scores, mapping the obtained key parameters of components to the corresponding static base scores, and outputs these static base scores as the second feature parameter.

[0056] Specifically, the vehicle terminal extracts the event trigger time (i.e., the timestamp of data generation) tagged during the encapsulation of each diagnostic dataset and reads the local current system time. The vehicle terminal calculates the time difference (in seconds) between the current time and the trigger time. Since newly generated data has far greater reference value for real-time fault diagnosis than outdated data, the vehicle terminal calculates this time difference according to a preset exponential decay function and outputs the calculation result as the third feature parameter.

[0057] As can be seen, in this embodiment, the combination of static component safety level and dynamic time decay factor for joint extraction by the vehicle terminal can objectively reflect the inherent security importance and real-time freshness of the data. The entire multi-dimensional feature extraction process is completed automatically in closed loop by the vehicle terminal without manual intervention, and it supports hardware architecture expansion to adapt to different vehicle models by updating the local vehicle configuration file.

[0058] Optionally, after obtaining the first feature parameter of each diagnostic dataset, the method further includes: detecting the current operating condition of the target vehicle; if the operating condition is a preset feature condition, determining the diagnostic dataset associated with the operating condition; obtaining the condition correction coefficient corresponding to the operating condition; and correcting the first feature parameter of the associated diagnostic dataset according to the condition correction coefficient corresponding to the operating condition to obtain the improved first feature parameter.

[0059] Among them, operating condition refers to the current overall driving state or working environment mode of the target vehicle, such as rapid acceleration, rapid deceleration, high-speed driving, cold start in low temperature, climbing, etc. Preset characteristic operating condition refers to a predefined specific operating condition that has a significant impact on the vehicle's power performance or safety sensitivity (such as rapid acceleration or cold start in low temperature). Operating condition correction coefficient is a scaling factor greater than 1 used to amplify or compensate for the fault correlation of relevant datasets under specific operating conditions.

[0060] Specifically, the vehicle terminal detects the current operating condition of the target vehicle by real-time analysis of status signals such as vehicle speed, acceleration, and ambient temperature on the vehicle bus. The vehicle terminal compares the detected operating condition with a locally stored pre-defined characteristic operating condition library to determine if it is under a special operating condition. If it is under a pre-defined characteristic operating condition, the vehicle terminal further determines a diagnostic dataset strongly correlated with the current operating condition based on a local operating condition association mapping table. Subsequently, the vehicle terminal reads the operating condition correction coefficient corresponding to that operating condition. Since fluctuations in certain regular data items often indicate more serious potential faults under extreme or special operating conditions, the vehicle terminal corrects the first feature parameter of the associated diagnostic dataset based on this operating condition correction coefficient (e.g., multiplying the original first feature parameter by the coefficient and truncating the upper limit), outputting the improved first feature parameter.

[0061] For example, the vehicle terminal detects that the target vehicle is currently in a preset characteristic condition of "rapid acceleration". The vehicle terminal queries the local mapping table to determine that the diagnostic dataset associated with rapid acceleration is "maximum discharge current of the power battery" and "motor torque request". The vehicle terminal obtains the condition correction coefficient corresponding to "rapid acceleration" as 1.2. Assuming that the first characteristic parameter F of "maximum discharge current of the power battery" was previously calculated to be 0.6, the vehicle terminal corrects it according to this correction coefficient: 0.6 × 1.2 = 0.72 (if the result exceeds 1.0, it is truncated to 1.0), and finally outputs the improved first characteristic parameter F = 0.72.

[0062] As can be seen, in this embodiment, by combining the vehicle terminal with real-time operating conditions to dynamically correct and compensate the feature parameters, the diagnostic weight of key data under special operating conditions can be effectively amplified, ensuring that core abnormal data of the vehicle under extreme or high load conditions are prioritized for identification and uploading. The entire dynamic adjustment process is automatically executed on the vehicle terminal without cloud or manual intervention, which significantly improves the accuracy of remote diagnosis under complex operating conditions.

[0063] S3: Based on the diagnostic value weight corresponding to each diagnostic dataset, obtain the target compression level corresponding to each diagnostic dataset.

[0064] The target compression level refers to the specific algorithm and compression ratio used by the vehicle terminal to compress the diagnostic dataset to be uploaded, and is classified into different levels. For example, the target compression level can be divided into lossless compression (level 0), low-loss high-fidelity compression (level 1), and high compression ratio compression (level 2).

[0065] Specifically, the vehicle terminal acquires the diagnostic value weight corresponding to each calculated diagnostic dataset. Since the diagnostic value weight directly reflects the importance of the data to fault diagnosis, the vehicle terminal maps the diagnostic value weight of each diagnostic dataset to the corresponding target compression level according to a locally preset "weight range and compression level mapping table". Because high-value data needs to retain as much original detail as possible for accurate cloud analysis, while low-value data will cause transmission congestion if it consumes too much bandwidth, the vehicle terminal assigns lossless or low compression ratio target compression levels to high-weight diagnostic datasets and high compression ratio target compression levels to low-weight diagnostic datasets.

[0066] For example, the vehicle terminal acquires three diagnostic datasets and their weights: "Individual Unit Temperature Sequence" (W=0.97), "Door Status Sequence" (W=0.40), and "Entertainment System Log" (W=0.15). The vehicle terminal reads its local mapping table and learns that: W≥0.8 corresponds to level 0 (lossless compression), 0.4≤W<0.8 corresponds to level 1 (normal compression), and W<0.4 corresponds to level 2 (high compression). Based on this, the vehicle terminal maps the weight 0.97 of the "Individual Unit Temperature Sequence" to target compression level 0, the weight 0.40 of the "Door Status Sequence" to target compression level 1, and the weight 0.15 of the "Entertainment System Log" to target compression level 2.

[0067] As can be seen, in this embodiment, the compression level is dynamically allocated based on the diagnostic value weight of the data itself by the vehicle terminal, which realizes on-demand compression. While ensuring lossless or low-loss transmission of core fault characteristics, the volume of low-value redundant data is reduced. The entire classification process is automatically executed in a closed loop by the vehicle terminal, which effectively optimizes the data upload efficiency and traffic cost in the narrowband environment of the vehicle.

[0068] S4: Based on the target compression level corresponding to each diagnostic dataset, compress each diagnostic dataset to obtain each compressed diagnostic dataset.

[0069] In one embodiment, the step of compressing each diagnostic dataset according to a target compression level to obtain a compressed diagnostic dataset includes: determining whether each diagnostic dataset belongs to a preset discrete key field type, wherein the preset discrete key field type includes fault diagnosis code, security status word, and fault snapshot; if each diagnostic dataset belongs to the preset discrete key field type, then compressing each diagnostic dataset according to a lossless compression mode to obtain the compressed diagnostic dataset; or, if each diagnostic dataset does not belong to the preset discrete key field type, then determining a corresponding compression mode according to the target compression level and the data type of each diagnostic dataset, and compressing each diagnostic dataset according to the determined compression mode to obtain the compressed diagnostic dataset; wherein, if the target compression level is a lossless compression level, then when each diagnostic dataset belongs to a switch type, a lossless compression mode is used. Each diagnostic dataset is compressed using a lossless compression algorithm based on dictionary matching; alternatively, when each diagnostic dataset does not belong to the switch quantity type, a preset lossless compression algorithm is used to compress each diagnostic dataset; alternatively, if the target compression level is a lightly lossy compression level, when each diagnostic dataset belongs to the continuous analog quantity type, time-domain differential coding combined with a lossy compression algorithm is used to compress each diagnostic dataset; alternatively, when each diagnostic dataset does not belong to the continuous analog quantity type, a preset lightly lossy compression algorithm is used to compress each diagnostic dataset; alternatively, if the target compression level is a heavily compression level, when each diagnostic dataset belongs to the high-frequency waveform type, frequency domain transformation is used to transform each diagnostic dataset, extracting the corresponding main frequency component and filtering out high-frequency noise; alternatively, when each diagnostic dataset does not belong to the high-frequency waveform type, a preset heavily compression algorithm is used to compress each diagnostic dataset. Among them, the preset discrete key field types refer to strongly constrained data types that involve core logic related to driving safety and faults, and absolutely prohibit bit-level loss or distortion. These include Diagnostic Troubleshooting Codes (DTCs), safety status words, and fault snapshots. Any loss of this type of data will lead to misdiagnosis in the cloud.

[0070] Among them, lossless compression mode refers to a compression mechanism that only eliminates statistical redundancy in the data without losing any valid information, and can completely restore the original data after decompression.

[0071] Among them, switch type refers to a data type with only two or a few discrete state values ​​(such as 0 / 1, on / off), which usually has a large number of repetitive states.

[0072] Among them, lossless compression algorithms based on dictionary matching refer to algorithms that reduce size by constructing a dynamic dictionary table and replacing consecutively repeated character strings with short index identifiers (such as the LZ77 algorithm).

[0073] Among them, the preset lossless compression algorithm refers to a general, standardized lossless compression algorithm (such as the Deflate algorithm) that is independent of the specific physical type of data, and combines Huffman coding to eliminate coding redundancy.

[0074] Among them, continuous analog quantity type refers to physical quantity signals that change continuously with time (such as battery voltage and coolant temperature), and there is often a strong time domain correlation between adjacent sampling points.

[0075] Among them, time-domain differential coding refers to not directly transmitting the absolute value of each sampling point, but only calculating and transmitting the difference increment between two adjacent sampling points.

[0076] Among them, lossy compression algorithms refer to compression algorithms that allow the discarding of some minor precision information (such as truncating low-order bits or uniform quantization coding) while preserving the core trend of the data.

[0077] Among them, the preset lightly lossy compression algorithm refers to a general algorithm that uses appropriate step-size quantization or downsampling for non-continuous analog data (such as counter values) to achieve a certain compression ratio with a small loss of precision.

[0078] Among them, high-frequency waveforms refer to signals with extremely high sampling frequencies, rich frequency domain characteristics, and large data volumes (such as motor vibration signals and inverter current waveforms).

[0079] Frequency domain transformation refers to mapping the amplitude sequence in the time domain to a spectral distribution in the frequency domain through mathematical transformations (such as Fast Fourier Transform, FFT). Preset heavy compression algorithm refers to an algorithm that, for non-high-frequency waveform data, uses extremely high downsampling rates or retains only extreme points to pursue the maximum compression ratio.

[0080] Specifically, before triggering compression, the vehicle terminal first parses the data tags on each diagnostic dataset to determine whether they belong to a preset discrete key field type. Since this type of data is involved in core fault diagnosis, any bit distortion will lead to serious misdiagnosis in the cloud. Therefore, if it is determined to belong to this type, the vehicle terminal directly ignores the target compression level calculated above and forcibly calls the lossless compression mode to encode and compress it, ensuring that the data is 100% restored.

[0081] Specifically, if the vehicle terminal determines that the diagnostic dataset does not belong to the preset discrete key field type, it enters a multi-level adaptive matching process. The vehicle terminal reads the target compression level and data type corresponding to the diagnostic dataset to determine the corresponding compression mode: when the target compression level is lossless compression, the vehicle terminal further determines whether it belongs to the switch quantity type. If so, since switch quantities have a large number of consecutive identical states, the vehicle terminal uses a dictionary-based lossless compression algorithm to compress it, replacing long strings of repeated states with short dictionary indices; if not, the vehicle terminal uses a preset lossless compression algorithm for general compression.

[0082] Specifically, when the target compression level is a slightly lossy compression level, the vehicle terminal determines whether it belongs to the continuous analog quantity type. If so, since the numerical changes of continuous physical quantities between adjacent time points are usually small, the vehicle terminal uses time-domain differential coding to calculate the difference between adjacent sampling points and combines it with a lossy compression algorithm to compress the difference sequence; if not, the vehicle terminal uses a preset slightly lossy compression algorithm to perform appropriate dimensionality reduction.

[0083] Specifically, when the target compression level is heavy compression, the vehicle terminal determines whether it belongs to a high-frequency waveform type. If so, since high-frequency waveforms have a large time domain volume and key information is hidden in the frequency band distribution, the vehicle terminal uses frequency domain transformation to transform it, extract the main frequency component corresponding to the dataset and filter out high-frequency noise, retaining only the characteristic frequency band to achieve an extremely high compression ratio; if not, the vehicle terminal uses a preset heavy compression algorithm to perform extremely high dimensionality reduction.

[0084] For example, the vehicle terminal filters out multiple datasets to be processed. For the dataset "DTC U0123 (BMS communication loss)," the vehicle terminal determines it belongs to the fault diagnosis code in the preset discrete key field type, forces the use of LZ77 lossless compression mode for compression, and outputs the compressed dataset. For the "individual temperature sequence" (a non-discrete key field, with a target compression level of light lossy compression, belonging to the continuous analog quantity type), the vehicle terminal calculates the difference between adjacent temperature sampling points (e.g., 30.5, 30.6, 30.6 converted to difference +0.1, 0), truncates it to one decimal place, and completes compression using a lossy compression algorithm. For a certain "original waveform of high-frequency vibration of a motor" (a non-discrete key field, with a target compression level of heavy compression, belonging to the high-frequency waveform type), the vehicle terminal uses Fast Fourier Transform (FFT) to process it, extracting the top 10 main frequency components with the largest amplitude and discarding the remaining high-frequency noise bands, transforming the large time-domain waveform into an extremely short frequency-domain feature sequence, completing heavy compression.

[0085] As can be seen, in this embodiment, the vehicle terminal takes the security attributes of the data as the absolute red line and combines the dual dimensions of target compression level and data type to perform adaptive algorithm matching. Under the premise of ensuring that the core security data is absolutely lossless, the most suitable dimensionality reduction strategy is adopted for data with different physical characteristics. The entire multi-level compression process is automatically executed on the vehicle terminal without cloud or manual intervention, which reduces the data transmission load while ensuring the effectiveness of diagnosis.

[0086] In one embodiment, after obtaining each compressed diagnostic dataset, the method further includes: obtaining the current network link quality parameters of the target vehicle and obtaining the processor utilization rate of the vehicle terminal; if the network link quality parameters are lower than a preset quality threshold, increasing the compression intensity corresponding to the target compression level to obtain an adjusted compression intensity; recompressing each diagnostic dataset according to the adjusted compression intensity to obtain each adjusted compressed diagnostic dataset; or, if the processor utilization rate exceeds a preset utilization rate threshold, switching the currently used compression method to a preset low-complexity compression algorithm; recompressing each diagnostic dataset according to the preset low-complexity compression algorithm to obtain each adjusted compressed diagnostic dataset.

[0087] Among them, network link quality parameters refer to comprehensive indicators used to characterize the communication channel status between the vehicle terminal and the cloud server. They can usually be calculated from parameters such as signal strength (RSSI), signal-to-noise ratio (SNR), or network packet loss rate.

[0088] Among them, the preset quality threshold refers to the critical value of link quality that the system pre-sets to ensure the stability of basic data transmission.

[0089] Compression intensity refers to the refined adjustment parameters (such as modifying the quantization step size or filter order) that control the compression ratio and data loss rate at a specific compression level.

[0090] Among them, the preset low-complexity compression algorithm refers to a data compression algorithm with extremely low computational overhead and minimal CPU power consumption (such as run-length encoding (RLE) or simple differential encoding), which is used to ensure that the basic compression function does not block the system when computing power is critical.

[0091] Specifically, after initial compression, the vehicle-mounted terminal detects and acquires the current network link quality parameters of the target vehicle in real time. Simultaneously, it reads performance monitoring data from the operating system's underlying layer to obtain the terminal's own processor utilization. The vehicle-mounted terminal compares the acquired network link quality parameters with a preset quality threshold stored locally. Since excessively large data packets can easily cause congestion and packet loss when network link quality deteriorates, if the network link quality parameters fall below the preset quality threshold, the vehicle-mounted terminal increases the corresponding compression intensity based on the current target compression level (for example, further reducing the frequency domain truncation component in the heavy compression level), obtaining an adjusted compression intensity. Subsequently, the vehicle-mounted terminal recompresses each diagnostic dataset based on this adjusted compression intensity, outputting the adjusted compressed dataset.

[0092] Specifically, the vehicle terminal compares the obtained processor utilization rate with a preset utilization rate threshold. Since complex frequency domain transformations or high-order dictionary matching consume a large number of CPU cycles, forcibly executing them when computing power is critical may cause the vehicle's basic diagnostic tasks to freeze. Therefore, if the processor utilization rate exceeds the preset utilization rate threshold, the vehicle terminal forcibly switches the currently used complex compression method (such as FFT transform) to a preset low-complexity compression algorithm. Subsequently, the vehicle terminal recompresses each diagnostic dataset according to this preset low-complexity compression algorithm and outputs the adjusted compressed dataset.

[0093] As can be seen, in this embodiment, the vehicle terminal can perceive the computing power bottleneck and network communication environment in real time, and dynamically downgrade or adjust the compression strategy when the threshold is triggered. This can effectively avoid transmission congestion in weak network environments and system jamming under high load. The entire adaptive adjustment process is automatically executed in a closed loop on the vehicle terminal without cloud or manual intervention, which improves the robustness of data upload in complex operating conditions.

[0094] S5: Based on the diagnostic value weight corresponding to each diagnostic dataset, each compressed diagnostic dataset is assigned to a corresponding target transmission queue, wherein different target transmission queues correspond to different transmission execution orders.

[0095] In one embodiment, the target transmission queue includes a high-priority transmission queue, a medium-priority transmission queue, and a low-priority transmission queue. The step of allocating each compressed diagnostic dataset to a corresponding target transmission queue based on the diagnostic value weight corresponding to each diagnostic dataset includes: if the diagnostic value weight corresponding to each diagnostic dataset is greater than or equal to a first preset threshold, then allocating each diagnostic dataset to the high-priority transmission queue; or, if the diagnostic value weight corresponding to each diagnostic dataset is less than the first preset threshold but greater than or equal to a second preset threshold, then allocating each diagnostic dataset to the medium-priority transmission queue; or, if the diagnostic value weight corresponding to each diagnostic dataset is less than the second preset threshold, then allocating each diagnostic dataset to the low-priority transmission queue, where the first preset threshold is greater than the second preset threshold.

[0096] The target transmission queue refers to a cache area in the vehicle terminal's local memory used to temporarily store data to be uploaded and control the order in which it is sent to the cloud. Different target transmission queues correspond to different transmission execution orders. That is, data packets in high-priority queues will be read and sent first by the vehicle terminal's communication scheduling module, while data packets in low-priority queues must wait until the high-priority and medium-priority queues have finished sending or the network is idle before they can be sent.

[0097] Among them, the high-priority transmission queue is a dedicated queue for storing datasets with extremely high diagnostic value and stringent real-time requirements (such as activated DTC-related data). The medium-priority transmission queue is a queue for storing datasets with some diagnostic reference value and tolerating very short latency (such as routine status signals). The low-priority transmission queue is a queue for storing datasets with lower diagnostic value, tolerating larger latency, or even those that can be discarded during network congestion (such as entertainment system logs).

[0098] The first and second preset thresholds are locally preset critical weight parameters used by the vehicle terminal to classify the importance gradient of data (e.g., the first preset threshold is set to 0.8 and the second preset threshold to 0.4). Specifically, after the vehicle terminal completes data compression and outputs each compressed diagnostic dataset, it extracts the diagnostic value weight calculated in the previous stage. The vehicle terminal compares this weight value with the locally stored first and second preset thresholds to determine its importance tier. If the diagnostic value weight is greater than or equal to the first preset threshold, it indicates that the dataset contains core fault features, and the vehicle terminal directly allocates the compressed dataset to the high-priority transmission queue to ensure it enjoys absolute priority in the communication link. If the diagnostic value weight is between the two thresholds, the vehicle terminal allocates it to the medium-priority transmission queue for normal queuing. If the diagnostic value weight is less than the second preset threshold, it indicates that the dataset contributes very little to fault diagnosis, and the vehicle terminal allocates it to the low-priority transmission queue to fill network bandwidth during idle periods.

[0099] For example, the vehicle terminal acquires three compressed diagnostic datasets and their weights: "Individual Temperature Sequence" (W=0.97), "Vehicle Speed ​​Sequence" (W=0.55), and "Air Conditioning Status Sequence" (W=0.15). The vehicle terminal reads the first preset threshold of 0.8 and the second preset threshold of 0.4. The vehicle terminal compares and finds that 0.97 ≥ 0.8, so it allocates the "Individual Temperature Sequence" to the high-priority transmission queue and triggers the communication module to immediately package and upload it; 0.4 ≤ 0.55 < 0.8, so it allocates the "Vehicle Speed ​​Sequence" to the medium-priority transmission queue and waits for the high-priority data to be sent before polling and sending it; 0.15 < 0.4, so it allocates the "Air Conditioning Status Sequence" to the low-priority transmission queue and only sends it if there is remaining bandwidth in the current network.

[0100] As can be seen, in this embodiment, the vehicle terminal uses diagnostic value weight as the sole guide to automatically divide the massive data stream to be uploaded into multi-level transmission queues, realizing the precise allocation of limited network bandwidth resources on demand. This ensures that high-value core fault data arrives at the cloud with minimal delay. The entire queuing and scheduling process is automatically executed in a closed loop at the vehicle terminal without cloud or manual intervention, improving the timeliness of remote diagnosis and the overall robustness of data transmission in weak network environments.

[0101] In one embodiment, before scheduling and transmitting each compressed diagnostic dataset according to the transmission execution order corresponding to each target transmission queue, the method further includes: obtaining the diagnostic value weight currently corresponding to each diagnostic dataset; if the transmission queue corresponding to the numerical range of the diagnostic value weight currently corresponding to each diagnostic dataset is inconsistent with the transmission queue currently corresponding to each diagnostic dataset, then migrating each diagnostic dataset to the transmission queue corresponding to the numerical range of the diagnostic value weight currently corresponding to each diagnostic dataset.

[0102] The corresponding diagnostic value weight refers to the dynamic weight value recalculated by the vehicle terminal based on the latest real-time status of the vehicle (such as newly received DTC activation, time decay accumulation, sudden changes in operating conditions, etc.) before the data packet is actually sent out of the vehicle terminal. The numerical interval refers to the weight segment (such as [0.8, 1], [0.4, 0.8], [0, 0.4)) divided by the first and second preset thresholds, and each numerical interval is fixedly mapped to a target transmission queue.

[0103] Migration refers to the dynamic adjustment action of the vehicle terminal removing the data packet pointer or entity temporarily stored in the local buffer from the original queue's linked list and re-inserting it into the corresponding priority position of the new queue.

[0104] Specifically, because vehicle status can change drastically within milliseconds (e.g., no fault occurred one second, a serious DTC is triggered the next), the diagnostic value weights calculated during early queue allocation may have become invalid. Therefore, before formal scheduling and transmission, the vehicle terminal's scheduling engine rereads the latest local status, recalculates the diagnostic value weight for each diagnostic dataset, and obtains its current corresponding diagnostic value weight. Based on the numerical range of this latest weight, the vehicle terminal determines the target transmission queue to which the dataset should belong and compares it with the actual transmission queue in which the dataset currently resides. If the two are inconsistent, it indicates a significant change in the urgency of the dataset. The vehicle terminal automatically extracts the dataset from the current queue and migrates it to the transmission queue corresponding to the latest weight range for re-queueing.

[0105] For example, at time T0, the vehicle terminal allocates the "brake pressure signal" dataset to the medium-priority transmission queue based on its current weight of 0.5. Just before scheduled transmission at time T1, the vehicle suddenly triggers a "brake system malfunction" DTC. The vehicle terminal recalculates the diagnostic value weight corresponding to the "brake pressure signal," and the value spikes to 0.95. The vehicle terminal determines that the value range [0.8, 1] corresponding to 0.95 belongs to the high-priority transmission queue, which is inconsistent with its current medium-priority transmission queue. The vehicle terminal then removes the "brake pressure signal" data packet from the medium-priority queue and moves it to the tail of the high-priority transmission queue, allowing it to be transmitted preferentially with the next communication frame.

[0106] As can be seen, by introducing a dynamic re-inspection and cross-queue migration mechanism through the vehicle terminal before the data is officially sent to the cloud, this embodiment can effectively cope with the ever-changing operating status of the vehicle, ensure that the priority of data transmission always matches its latest real diagnostic value, and the entire reordering and migration process is automatically executed in a closed loop on the vehicle terminal without cloud or manual intervention, thus completely avoiding the risk that high-value fault data will be delayed due to early low-weight rating.

[0107] S6: According to the transmission execution order corresponding to each target transmission queue, schedule the transmission of each compressed diagnostic dataset to transmit each compressed diagnostic dataset to the cloud diagnostic platform, which is communicatively connected to the vehicle terminal.

[0108] In one embodiment, the target transmission queue includes a high-priority transmission queue, a medium-priority transmission queue, and a low-priority transmission queue; the step of scheduling the transmission of each compressed diagnostic dataset according to the transmission execution order corresponding to each target transmission queue includes: determining whether there is a diagnostic dataset to be transmitted in the high-priority transmission queue; if so, prioritizing the transmission of the diagnostic dataset in the high-priority transmission queue and interrupting the scheduling and transmission of the diagnostic dataset in the medium-priority transmission queue and the low-priority transmission queue; or, if there is no diagnostic dataset to be transmitted in the high-priority transmission queue, sequentially scheduling the transmission of the diagnostic dataset in the medium-priority transmission queue and the low-priority transmission queue.

[0109] The cloud-based diagnostic platform refers to a remote business system deployed on a cloud server side, used to receive data reported by vehicles and perform fault analysis, health assessment, and visualization. The cloud-based diagnostic platform and the vehicle terminal establish a two-way communication connection through a cellular network (such as 4G / 5G).

[0110] The transmission execution order refers to the absolute order in which the local communication scheduling module of the vehicle terminal reads data packets from each queue and sends them over the network. In this embodiment, the execution logic of "high priority absolutely preempts, medium priority next, and low priority as a fallback" is strictly followed.

[0111] Interruption refers to the preemptive scheduling behavior in which, when a high-priority queue suddenly receives new data, the vehicle terminal immediately suspends the current packet assembly or transmission of low-priority queue data packets and instead transfers all communication link resources to the high-priority data.

[0112] Specifically, when the communication scheduling module of the vehicle terminal executes a network transmission task, it first polls to determine whether there are diagnostic datasets to be transmitted in the high-priority transmission queue. If so, because such datasets (such as activated DTC-related data) have the highest level of transmission urgency, the vehicle terminal prioritizes the transmission of diagnostic datasets in the high-priority transmission queue. If the medium-priority or low-priority queues are currently transmitting, the vehicle terminal forcibly interrupts the scheduled transmission of diagnostic datasets in the medium-priority and low-priority transmission queues, and devotes all communication bandwidth to high-priority data until the high-priority queue is cleared.

[0113] Specifically, if the vehicle terminal determines that there are no diagnostic datasets to be transmitted in the high-priority transmission queue, it means that there are no urgent faults or core safety data that need to be reported. At this time, the vehicle terminal releases the communication link and sequentially schedules the transmission of diagnostic datasets in the medium-priority and low-priority transmission queues. That is, it first sends the routine status data in the medium-priority queue, and after the medium-priority queue is cleared, it sends the non-critical log data in the low-priority queue.

[0114] For example, the vehicle terminal is sequentially sending "entertainment system log" data packets from a low-priority queue. During this time, the vehicle suddenly triggers a "power steering failure" fault, and the vehicle terminal stores the relevant "steering torque data" in a high-priority transmission queue. In the next poll, the vehicle terminal scheduling module determines that there is data to be transmitted in the high-priority transmission queue, immediately interrupts the current "entertainment system log" transmission, prioritizes the "steering torque data" packet, and sends it to the cloud diagnostic platform at full speed. Only after the high-priority queue is cleared does the vehicle terminal resume interrupted transmission from the low-priority queue.

[0115] As can be seen, the strict queue priority preemptive scheduling mechanism implemented by the vehicle terminal in this embodiment can ensure that in the event of a sudden serious fault, the core diagnostic data can be accessed to the cloud in seconds without queuing or waiting for network resources. The entire scheduling and transmission process is automatically executed in a closed loop on the vehicle terminal without cloud or manual intervention, which fundamentally guarantees the real-time performance and reliability of remote vehicle fault diagnosis.

[0116] Optionally, after transmitting each compressed diagnostic dataset to the cloud diagnostic platform, the method further includes: receiving a parameter update instruction issued by the cloud diagnostic platform, wherein the parameter update instruction is generated by the cloud diagnostic platform through AI analysis of each compressed diagnostic dataset and when it is identified that the frequency of failure of a specific component in the target area is greater than a preset frequency threshold; updating the local weight evaluation algorithm parameters of the vehicle terminal according to the parameter update instruction; wherein the weight evaluation algorithm parameters include the component criticality static basic score and the fault correlation configuration coefficient; and recalculating the diagnostic value weight of subsequently acquired diagnostic datasets according to the updated weight evaluation algorithm parameters.

[0117] Among them, the parameter update instruction refers to an OTA (Over-The-Air) configuration message sent by the cloud diagnostic platform to a specific vehicle terminal or a specific model cluster after it has discovered the pattern of clustered faults across vehicles and regions. This message is used to dynamically optimize the diagnostic value assessment logic of the vehicle terminal.

[0118] AI analysis refers to the process by which cloud-based diagnostic platforms use big data mining and machine learning models to extract features and recognize patterns from massive amounts of compressed diagnostic datasets reported by vehicles in order to discover hidden systemic defects or regionally prevalent faults.

[0119] Among them, the weight evaluation algorithm parameters refer to the variables used to adjust the influence of each feature parameter in the preset weight evaluation algorithm formula (W=α.F+β.C+γ.T) of the vehicle terminal, including the static basic score corresponding to the criticality of the component (C value base table mapping relationship) and configurable coefficients (such as the α coefficient).

[0120] Specifically, after continuously receiving compressed diagnostic datasets reported by various vehicles, the cloud-based diagnostic platform decompresses them and inputs them into the cloud-based AI big data analysis model. When the AI ​​analysis model detects that the frequency of a certain type of signal (such as a specific model of temperature sensor) malfunctioning in a specific area exceeds a preset frequency threshold, it determines that the diagnostic value of that component in that scenario needs to be amplified. Based on this, the cloud-based diagnostic platform generates a parameter update instruction containing a new parameter configuration table and sends it to the vehicle terminal via the communication link. After receiving the instruction, the vehicle terminal parses and extracts the parameter configuration items, overwriting and updating the locally stored weight evaluation algorithm parameters. Subsequently, when the vehicle terminal obtains a new diagnostic dataset again, it will recalculate the diagnostic value weight based on the updated parameters (such as an increased C value or an adjusted α coefficient), realizing the online evolution of the vehicle terminal's data filtering strategy.

[0121] For example, the AI ​​analysis model of the cloud-based diagnostic platform, through in-depth analysis of data reported from cold northern regions, discovered that a certain model of external temperature sensor had an extremely high failure frequency in low-temperature environments. The cloud-based diagnostic platform determined that the diagnostic priority of this component on the vehicle's terminal needed to be increased, and therefore issued a parameter update command to the vehicle's terminal in that region. Upon receiving the command, the vehicle's terminal updated its local weighting algorithm parameters: increasing the static base score (C value) of the temperature sensor component from 0.6 to 0.85, and simultaneously increasing the fault correlation coefficient α from 1 / 3 to 0.5. Subsequently, when the vehicle generates diagnostic data for this temperature sensor again, the vehicle's terminal uses the new C value and α coefficient to calculate the weight, significantly increasing the diagnostic value weight of the dataset, thus making it more likely to be allocated to a high-priority transmission queue for priority uploading.

[0122] As can be seen, in this embodiment, through the collaborative closed loop between the vehicle terminal and the cloud diagnostic platform, the data value assessment model of the vehicle terminal is no longer a static configuration, but can be OTA online evolved based on the feedback of group fault characteristics from the global perspective of the cloud.

[0123] This embodiment calculates the diagnostic value weight for each diagnostic dataset of the target vehicle and determines the corresponding target compression level based on this weight, thereby performing differentiated compression processing on the diagnostic datasets. This changes the processing method of using a uniform compression standard for all diagnostic data, allowing data with different diagnostic values ​​to receive compression intensity commensurate with their importance. This effectively reduces the overall data processing and storage overhead while ensuring the processing effect of important diagnostic data. Simultaneously, each compressed diagnostic dataset is allocated to a corresponding target transmission queue based on its diagnostic value weight, and the compressed diagnostic datasets are scheduled for transmission according to the transmission execution order corresponding to different target transmission queues. This ensures that data with different diagnostic values ​​are transmitted to the cloud diagnostic platform in an order commensurate with their importance, avoiding the problem of unreasonable allocation of transmission resources caused by indiscriminate transmission of various types of diagnostic data. Therefore, this embodiment uses the calculation results of diagnostic value weights to guide compression processing and transmission queue allocation and scheduling, realizing that both compression strategies and transmission scheduling revolve around diagnostic value weights. This allows the vehicle terminal to perform targeted compression and transmission processing based on the value differences of the diagnostic datasets, improving the rationality and effectiveness of the overall diagnostic data processing and transmission process under limited processing and transmission resources.

[0124] Please see Figure 4 As shown, in one embodiment, a vehicle-mounted data dynamic hierarchical compression and priority transmission device is provided, the device 400 comprising: Acquisition unit 401 is used to acquire multiple diagnostic datasets for the target vehicle; Processing unit 402 is used to calculate the diagnostic value weight corresponding to each diagnostic dataset for each diagnostic dataset; The processing unit 402 is further configured to obtain the target compression level corresponding to each diagnostic dataset based on the diagnostic value weight corresponding to each diagnostic dataset; The processing unit 402 is further configured to compress each diagnostic dataset according to the target compression level corresponding to each diagnostic dataset, so as to obtain each compressed diagnostic dataset. The processing unit 402 is further configured to allocate each compressed diagnostic dataset to a corresponding target transmission queue according to the diagnostic value weight corresponding to each diagnostic dataset, wherein different target transmission queues correspond to different transmission execution orders; The transmission unit 403 is used to schedule the transmission of each compressed diagnostic dataset according to the transmission execution order corresponding to each target transmission queue, so as to transmit each compressed diagnostic dataset to the cloud diagnostic platform, which is communicatively connected to the vehicle terminal.

[0125] This embodiment calculates the diagnostic value weight for each diagnostic dataset of the target vehicle and determines the corresponding target compression level based on this weight, thereby performing differentiated compression processing on the diagnostic datasets. This changes the processing method of using a uniform compression standard for all diagnostic data, allowing data with different diagnostic values ​​to receive compression intensity commensurate with their importance. This effectively reduces the overall data processing and storage overhead while ensuring the processing effect of important diagnostic data. Simultaneously, each compressed diagnostic dataset is allocated to a corresponding target transmission queue based on its diagnostic value weight, and the compressed diagnostic datasets are scheduled for transmission according to the transmission execution order corresponding to different target transmission queues. This ensures that data with different diagnostic values ​​are transmitted to the cloud diagnostic platform in an order commensurate with their importance, avoiding the problem of unreasonable allocation of transmission resources caused by indiscriminate transmission of various types of diagnostic data. Therefore, this embodiment uses the calculation results of diagnostic value weights to guide compression processing and transmission queue allocation and scheduling, realizing that both compression strategies and transmission scheduling revolve around diagnostic value weights. This allows the vehicle terminal to perform targeted compression and transmission processing based on the value differences of the diagnostic datasets, improving the rationality and effectiveness of the overall diagnostic data processing and transmission process under limited processing and transmission resources.

[0126] It should be noted that the above-mentioned vehicle-mounted data dynamic hierarchical compression and priority transmission device can execute the vehicle-mounted data dynamic hierarchical compression and priority transmission method provided in the embodiments of this application, and has the corresponding functional modules and beneficial effects of the method. Technical details not described in detail in the embodiments of the vehicle-mounted data dynamic hierarchical compression and priority transmission device can be found in the vehicle-mounted data dynamic hierarchical compression and priority transmission method provided in the embodiments of this application.

[0127] This application also provides a computer-readable storage medium storing a computer program, the computer program including program instructions, which, when executed by a processor, cause the processor to perform the vehicle data dynamic hierarchical compression and priority transmission method as described in the foregoing embodiments.

[0128] It should be noted that the functions or steps that can be implemented by the computer-readable storage medium or computer device described above can be referred to the relevant descriptions on the server side and client side in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0129] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program 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, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0130] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0131] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A method for dynamic hierarchical compression and prioritized transmission of vehicle-mounted data, characterized in that, Applied to vehicle-mounted terminals, the method includes: Obtain multiple diagnostic datasets for the target vehicle; For each diagnostic dataset, the diagnostic value weight corresponding to each diagnostic dataset is calculated; Based on the diagnostic value weight corresponding to each diagnostic dataset, the target compression level corresponding to each diagnostic dataset is obtained; Based on the target compression level corresponding to each diagnostic dataset, each diagnostic dataset is compressed to obtain each compressed diagnostic dataset. Based on the diagnostic value weight corresponding to each diagnostic dataset, each compressed diagnostic dataset is assigned to a corresponding target transmission queue, wherein different target transmission queues correspond to different transmission execution orders; According to the transmission execution order corresponding to each of the target transmission queues, each compressed diagnostic dataset is scheduled for transmission to the cloud diagnostic platform, which is communicatively connected to the vehicle terminal.

2. The method for dynamic hierarchical compression and priority transmission of vehicle-mounted data according to claim 1, characterized in that, The step of calculating the diagnostic value weight corresponding to each diagnostic dataset includes: Obtain the first feature parameter, the second feature parameter, and the third feature parameter for each diagnostic dataset; The first feature parameter, the second feature parameter, and the third feature parameter are weighted according to a preset weight evaluation algorithm to obtain the diagnostic value weight corresponding to each diagnostic dataset.

3. The method for dynamic hierarchical compression and priority transmission of vehicle-mounted data according to claim 2, characterized in that, The step of obtaining the first feature parameter of each diagnostic dataset includes: Determine whether the target vehicle currently has any activated fault diagnosis codes; If an activated fault diagnosis code exists, determine whether each diagnostic dataset is a signal associated with the activated fault diagnosis code. If each diagnostic dataset is a signal associated with an activated fault diagnosis code, then the first feature parameter of each diagnostic dataset is set to a preset maximum value; or, If there is no activated fault diagnosis code, or if each diagnostic dataset is not a signal associated with the activated fault diagnosis code, then historical fault data is obtained, and the frequency of occurrence of each diagnostic dataset in the same fault scenario is queried from the historical fault data. The occurrence frequency is normalized to obtain a normalized result, which is the first feature parameter of each diagnostic dataset.

4. The method for dynamic hierarchical compression and priority transmission of vehicle-mounted data according to claim 2, characterized in that, The process of obtaining the second and third feature parameters of each diagnostic dataset includes: Obtain the vehicle model configuration file for the target vehicle; In the vehicle configuration file, obtain the key parameters of the component corresponding to the component to which each diagnostic dataset belongs; Based on the mapping relationship between preset component key parameters and static base scores, the component key parameters corresponding to the component to which each diagnostic dataset belongs are mapped to the corresponding static base scores, and the static base scores are the second feature parameters of each diagnostic dataset. Obtain the trigger time of the event corresponding to each diagnostic dataset; Obtain the time difference between the current time and the trigger time; The time difference is calculated based on a preset exponential decay function to obtain the calculation result, which is the third feature parameter of each diagnostic dataset.

5. The method for dynamic hierarchical compression and priority transmission of vehicle-mounted data according to claim 1, characterized in that, The step of compressing each diagnostic dataset according to the target compression level corresponding to each diagnostic dataset to obtain each compressed diagnostic dataset includes: Determine whether each diagnostic dataset belongs to a preset discrete key field type, the preset discrete key field type including fault diagnosis code, safety status word and fault snapshot; If each diagnostic dataset belongs to the preset discrete key field type, then each diagnostic dataset is compressed according to the lossless compression mode to obtain the compressed diagnostic dataset; or, If each diagnostic dataset does not belong to the preset discrete key field type, then according to the target compression level corresponding to each diagnostic dataset and the data type to which each diagnostic dataset belongs, the corresponding compression mode is determined, and each diagnostic dataset is compressed according to the determined compression mode to obtain each compressed diagnostic dataset. Wherein, if the target compression level is a lossless compression level, then when each diagnostic dataset belongs to the switch type, a dictionary-matching-based lossless compression algorithm is used to compress each diagnostic dataset; or, when each diagnostic dataset does not belong to the switch type, a preset lossless compression algorithm is used to compress each diagnostic dataset; or... If the target compression level is a lightly lossy compression level, then when each diagnostic dataset belongs to the continuous analog quantity type, time-domain differential coding combined with a lossy compression algorithm is used to compress each diagnostic dataset; or, when each diagnostic dataset does not belong to the continuous analog quantity type, a preset lightly lossy compression algorithm is used to compress each diagnostic dataset; or... If the target compression level is a heavy compression level, then when each diagnostic dataset belongs to a high-frequency waveform type, a frequency domain transformation method is used to transform each diagnostic dataset, extract the main frequency component corresponding to each diagnostic dataset, and filter out high-frequency noise; or, when each diagnostic dataset does not belong to the high-frequency waveform type, a preset heavy compression algorithm is used to compress each diagnostic dataset.

6. The method for dynamic hierarchical compression and priority transmission of vehicle-mounted data according to claim 5, characterized in that, After obtaining each compressed diagnostic dataset, the method further includes: Obtain the current network link quality parameters of the target vehicle, and obtain the processor utilization rate of the vehicle terminal; If the network link quality parameter is lower than the preset quality threshold, the compression intensity corresponding to the target compression level is increased to obtain the adjusted compression intensity; Based on the adjusted compression strength, each diagnostic dataset is recompressed to obtain the adjusted compressed diagnostic dataset; or... If the processor utilization rate exceeds a preset utilization rate threshold, the current compression method will be switched to a preset low-complexity compression algorithm. According to the preset low-complexity compression algorithm, each diagnostic dataset is recompressed to obtain the adjusted compressed diagnostic dataset.

7. The method for dynamic hierarchical compression and priority transmission of vehicle-mounted data according to claim 1, characterized in that, The target transmission queue includes a high-priority transmission queue, a medium-priority transmission queue, and a low-priority transmission queue; the step of allocating each compressed diagnostic dataset to its corresponding target transmission queue according to the diagnostic value weight corresponding to each diagnostic dataset includes: If the diagnostic value weight corresponding to each diagnostic dataset is greater than or equal to a first preset threshold, then each diagnostic dataset is assigned to the high-priority transmission queue; or, If the diagnostic value weight corresponding to each diagnostic dataset is less than the first preset threshold and greater than or equal to the second preset threshold, then each diagnostic dataset is assigned to the medium-priority transmission queue; or, If the diagnostic value weight corresponding to each diagnostic dataset is less than the second preset threshold, then each diagnostic dataset is assigned to the low-priority transmission queue, where the first preset threshold is greater than the second preset threshold.

8. The method for dynamic hierarchical compression and priority transmission of vehicle-mounted data according to claim 1, characterized in that, Before scheduling the transmission of each compressed diagnostic dataset according to the transmission execution order corresponding to each of the target transmission queues, the method further includes: Obtain the diagnostic value weight corresponding to each diagnostic dataset at present; If the transmission queue corresponding to the numerical range of the diagnostic value weight currently corresponding to each diagnostic dataset is inconsistent with the transmission queue currently corresponding to each diagnostic dataset, then each diagnostic dataset will be migrated to the transmission queue corresponding to the numerical range of the diagnostic value weight currently corresponding to each diagnostic dataset.

9. The method for dynamic hierarchical compression and priority transmission of vehicle-mounted data according to claim 1, characterized in that, The target transmission queue includes a high-priority transmission queue, a medium-priority transmission queue, and a low-priority transmission queue; The step of scheduling the transmission of each compressed diagnostic dataset according to the transmission execution order corresponding to each target transmission queue includes: Determine whether a diagnostic dataset to be transmitted exists in the high-priority transmission queue; If present, the diagnostic dataset in the high-priority transmission queue is prioritized for transmission, and the transmission of the diagnostic dataset in the medium-priority and low-priority transmission queues is interrupted; or, If there is no diagnostic dataset to be transmitted in the high-priority transmission queue, then the diagnostic datasets in the medium-priority transmission queue and the low-priority transmission queue will be transmitted sequentially.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the vehicle data dynamic hierarchical compression and priority transmission method as described in any one of claims 1 to 9.

Images