Vehicle flow usage error correction method and device, target vehicle, and storage medium

Abstract

This invention relates to the field of in-vehicle infotainment system (IVS) data usage technology, specifically to an IVS data usage correction method, device, target vehicle, and storage medium. The method involves: obtaining the current IVS data usage for the target vehicle; calculating the target data usage deviation based on the current IVS data usage; determining the cause of the data usage deviation based on the deviation; and correcting the current IVS data usage for the target vehicle based on the cause of the deviation. This solves the problem of inaccurate IVS data usage statistics in existing technologies, resolves the discrepancy between operator-billed data usage and actual IVS data usage, protects the legitimate rights and interests of automakers and users, and promotes the healthy and sustainable development of connected vehicle services.

Description

Technical Field

[0001] This invention relates to the field of vehicle infotainment system data flow technology, specifically to a method, device, target vehicle, and storage medium for correcting vehicle infotainment system data flow usage errors. Background Technology

[0002] With the rapid development of vehicle-to-everything (V2X) technology, the popularity of features such as in-vehicle navigation, online entertainment, and OTA upgrades continues to increase. The traffic pool model has become the mainstream solution for automakers to provide in-vehicle network services to users. Specifically, automakers purchase traffic resources in bulk from telecommunications operators and build traffic pools. Then, based on the user's selected data plan, the resources within the traffic pool are allocated to the in-vehicle terminals of each vehicle as needed. Subsequently, automakers settle accounts with operators based on the traffic usage data of each individual in-vehicle terminal as compiled by the operators.

[0003] However, in the actual operation of the traffic pool model, the "scissors difference" between the billed traffic volume reported by operators and the actual traffic consumption by the vehicle's infotainment system has become increasingly prominent, becoming a key bottleneck restricting the commercial development of connected vehicles. When the traffic volume reported by operators exceeds the actual traffic volume consumed by the vehicle's infotainment system, it triggers a dual conflict between automakers and users. For users, the inflated traffic volume reported by operators leads to the rapid depletion of their data allowance, requiring them to purchase additional data packages or face the risk of network outages. This, in turn, leads to accusations that automakers are engaging in "falsely inflated traffic volume" or "hidden charges," resulting in numerous user complaints and severely damaging the automakers' brand image and user trust. For automakers, they have to pay additional settlement fees to operators for the inflated traffic volume reported by operators. This cost, which has no actual usage support, significantly erodes automakers' profits and reduces the profitability of connected vehicle services.

[0004] To address this industry pain point, existing technologies lack a complete and efficient mechanism for correcting data usage errors, failing to achieve a full-process processing loop of "data collection—deviation quantification and analysis—anomaly cause location—precise error correction." Neither automakers nor users can effectively prove that operators have overcharged them for data usage, nor can they recover the extra costs or restore the wrongly deducted data allowance, ultimately leaving both automakers and users in a passive position in data usage disputes.

[0005] Therefore, there is an urgent need to propose a method for correcting vehicle data usage, to solve the problem of inaccurate vehicle data usage statistics in existing technologies, to resolve the contradiction between the data usage billed by operators and the actual data usage of vehicle devices, to protect the legitimate rights and interests of car manufacturers and users, and to promote the healthy and sustainable development of vehicle networking services. Summary of the Invention

[0006] This invention provides a method, device, target vehicle, and storage medium for correcting vehicle infotainment system traffic usage, in order to solve the problem of inaccurate vehicle infotainment system traffic usage statistics.

[0007] In a first aspect, the present invention provides a method for correcting vehicle infotainment system traffic usage, the method comprising: obtaining the current vehicle infotainment system traffic usage corresponding to the target vehicle; calculating the target traffic usage deviation corresponding to the target vehicle based on the current vehicle infotainment system traffic usage; determining the cause of the traffic usage deviation based on the target traffic usage deviation; and correcting the current vehicle infotainment system traffic usage corresponding to the target vehicle based on the cause of the traffic usage deviation.

[0008] The vehicle-mounted system traffic usage correction method provided in this application obtains the current vehicle-mounted system traffic usage for the target vehicle. This solidifies the foundation of correction data, ensuring comprehensive and accurate original data for subsequent calculations and judgments, avoiding deviations in subsequent processes due to missing or distorted data. Based on the current vehicle-mounted system traffic usage, the method calculates the target traffic usage deviation for the target vehicle, quantifying the degree of deviation in traffic statistics. This provides measurable quantitative indicators for determining "abnormality" and "cause of deviation," allowing subsequent judgments to move beyond subjective assumptions. Based on the target traffic usage deviation, the method identifies the cause of the traffic usage deviation. It accurately locates the source of error (vehicle-mounted system / operator / scenario fluctuations), avoiding blind correction and providing direction for targeted handling, thus improving correction efficiency. Based on the cause of the traffic usage deviation, the method corrects the current vehicle-mounted system traffic usage for the target vehicle. This corrects inaccurate traffic records, reduces additional costs for automakers, decreases user complaints, and optimizes traffic pool parameters to reduce future deviations. This technology solves the problem of inaccurate vehicle data usage statistics in existing technologies, resolves the discrepancy between the data usage billed by operators and the actual data usage of vehicle systems, protects the legitimate rights and interests of car manufacturers and users, and promotes the healthy and sustainable development of connected vehicle services.

[0009] In one optional implementation, the target traffic usage deviation for the target vehicle is calculated based on the current vehicle-mounted system traffic usage, including: obtaining the traffic usage baseline data for the target vehicle; and calculating the target traffic usage deviation for the target vehicle based on the current vehicle-mounted system traffic usage and the traffic usage baseline data.

[0010] The vehicle data usage correction method provided in this application obtains baseline data on data usage, offering a "reference standard" that balances accuracy (aligning with actual vehicle data consumption) and authority (complying with operator compliance requirements). This provides a reliable basis for deviation calculation and avoids the limitations of a single data source. The method calculates the target data usage deviation. By comparing the deviation with the baseline data, the degree of deviation is quantified, clarifying the magnitude of the deviation in data usage statistics. This provides measurable indicators for subsequent anomaly detection and cause identification, making deviation assessment more objective and accurate.

[0011] In one optional implementation, the current vehicle-mounted system traffic usage includes the current local traffic data of the vehicle-mounted system and the current operator CDR data. Obtaining the traffic usage benchmark data corresponding to the target vehicle includes: constructing a state equation using the current local traffic data of the vehicle-mounted system as the observation value and the current operator CDR data as the reference value; constructing an observation equation based on the state equation; and calculating the traffic usage benchmark data corresponding to the target vehicle based on the observation equation.

[0012] The vehicle-mounted vehicle traffic usage correction method provided in this application constructs a state equation using the current local vehicle traffic data as the observed value and the operator's CDR data as the reference value. It quantifies the impact of scenario characteristics such as network type, application type, and time period on traffic data, eliminating inherent errors caused by scenario fluctuations. This ensures that the calculation of traffic usage benchmark data closely matches the actual vehicle usage scenario, avoiding the use of fixed standards to measure traffic data under different scenarios. Based on the state equation, an observation equation is constructed to accurately quantify the deviation between the vehicle-mounted vehicle local data, the operator's CDR data, and the theoretical true value after scenario adaptation. This provides a quantitative basis for subsequent dynamic correction, avoids subjective judgment errors, and ensures the objectivity of traffic usage benchmark data calculation. Based on the observation equation, the traffic usage benchmark data is calculated. By dynamically weighting and fusing dual-source data, a benchmark value that balances the accuracy of actual vehicle consumption and the authority of operator data is generated. This avoids the limitations of a single data source and provides a reliable "gold standard" for subsequent deviation calculation and anomaly detection.

[0013] In one optional implementation, the current vehicle-mounted system traffic usage includes at least one of the following: current vehicle-mounted system local traffic data, current carrier CDR data, and application layer API call data; based on the current vehicle-mounted system traffic usage and traffic usage benchmark data, the target traffic usage deviation corresponding to the target vehicle is calculated, including: calculating a first absolute value deviation between the current vehicle-mounted system local traffic data and the traffic usage benchmark data; calculating a second absolute value deviation between the current carrier CDR data and the traffic usage benchmark data; calculating a third absolute value deviation between the application layer API call data and the traffic usage benchmark data; and based on the first absolute value deviation, and / or the second absolute value deviation, and / or the third absolute value deviation, the target traffic usage deviation corresponding to the target vehicle is calculated.

[0014] The vehicle-mounted data usage error correction method provided in this application calculates a first absolute deviation to quantify the deviation between the vehicle-mounted data's local data usage and the baseline data usage, clarifying the degree of difference between the local data and the "gold standard," and providing a quantitative basis for locating local data anomalies. It then calculates a second absolute deviation to measure the magnitude of the deviation between the operator's CDR data and the baseline data usage, providing a quantitative indicator for judging the accuracy of the operator's billing data and the existence of statistical errors. Finally, it calculates a third absolute deviation to supplement the assessment of the fit between the application-layer estimated data and the baseline data usage, reflecting the accuracy of the scenario-based data usage model and improving the coverage of multi-dimensional deviation analysis. Based on these three types of deviations, it calculates the target data usage deviation. Through weighted or combined calculation of multi-source deviations, it obtains an indicator that comprehensively reflects the overall data usage statistical deviation, avoiding the one-sidedness of a single data source deviation and providing objective and comprehensive quantitative support for subsequent anomaly judgment and cause location.

[0015] In one optional implementation, determining the cause of the traffic usage deviation based on the target traffic usage deviation includes: obtaining the current traffic usage scenario characteristics corresponding to the target vehicle; the current traffic usage scenario characteristics include network type, application type, and current time period; determining the absolute deviation threshold range corresponding to the target traffic usage deviation based on the current traffic usage scenario characteristics; comparing the target traffic usage deviation with the absolute deviation threshold range; if the target traffic usage deviation exceeds the absolute deviation threshold range, then determining the cause of the traffic usage deviation based on the current traffic usage scenario characteristics.

[0016] The vehicle-mounted traffic usage correction method provided in this application obtains the characteristics of the current traffic usage scenario and extracts core dimension information of network, application, and time period. This provides a scenario-based basis for subsequent threshold setting and cause localization, avoiding a uniform judgment standard that is detached from the actual usage scenario. It determines the absolute deviation threshold range corresponding to the target traffic usage deviation and matches a reasonable deviation range based on scenario characteristics. This ensures that the threshold judgment fits the traffic fluctuation characteristics of different scenarios, reducing the probability of normal scenario fluctuations being misjudged as abnormal. The target traffic usage deviation is compared with the absolute deviation threshold range. Abnormal deviations are quickly screened out through quantitative comparison, clarifying the necessity of subsequent cause investigation and improving the objectivity and efficiency of deviation judgment. If the target traffic usage deviation exceeds the absolute deviation threshold range, the cause of the traffic usage deviation is determined based on the characteristics of the current traffic usage scenario. Combining scenario characteristics narrows the scope of cause investigation, accurately locating deviation sources strongly related to the scenario (such as base station switching errors during peak hours, video application bitrate fluctuation errors), avoiding blind investigation and improving the accuracy of cause localization.

[0017] In one optional implementation, the current vehicle infotainment system traffic usage includes the current local traffic data of the vehicle infotainment system, and the reasons for traffic usage deviation include abnormal local traffic data of the vehicle infotainment system. Based on the characteristics of the current traffic usage scenario, the reasons for traffic usage deviation are determined, including: based on the characteristics of the current traffic usage scenario, searching for historical local traffic data of the vehicle infotainment system that is consistent with the characteristics of the current traffic usage scenario from a preset historical traffic database; calculating a first similarity between the current local traffic data of the vehicle infotainment system and the historical local traffic data of the vehicle infotainment system; if the first similarity is less than a first preset similarity threshold, then the reason for traffic usage deviation is determined to be abnormal local traffic data of the vehicle infotainment system.

[0018] The vehicle-mounted data usage correction method provided in this application's embodiments searches for matching historical local data usage data of the vehicle-mounted system based on scene characteristics. It anchors historical data from the same scene as a reference benchmark, avoiding interference from data from different scenes and ensuring the rationality and comparability of subsequent similarity comparisons. It calculates the first similarity between the current data and historical local data, quantifying the degree of fit between the current data and historical data from the same scene, transforming the judgment of "whether it is abnormal" into a measurable numerical indicator, overcoming the limitations of subjective experience. It determines abnormalities in the local data of the vehicle-mounted system based on a similarity threshold. By filtering out abnormal data through clear threshold standards, it accurately locates the vehicle-mounted system-side causes of data usage deviations, providing a clear direction for subsequent targeted error correction and improving the efficiency and accuracy of deviation cause location.

[0019] In one optional implementation, the current vehicle data usage includes the current operator CDR data, and the reasons for data usage deviation include abnormal operator CDR data. Based on the characteristics of the current data usage scenario, the reasons for data usage deviation are determined, including: based on the characteristics of the current data usage scenario, searching for historical operator CDR data consistent with the characteristics of the current data usage scenario from a preset historical data database; calculating a second similarity between the current operator CDR data and the historical operator CDR data; if the second similarity is less than a second preset similarity threshold, then the reason for data usage deviation is determined to be abnormal operator CDR data.

[0020] The vehicle data usage correction method provided in this application's embodiments searches for matching historical operator CDR data based on scene characteristics. It anchors historical operator data from the same scene as a reference benchmark, ensuring scene consistency in the compared data and avoiding misjudgments due to scene differences. This provides a reasonable reference basis for determining operator data anomalies. The method calculates a second similarity between current and historical operator CDR data. The fit between current operator data and historical data from the same scene is converted into a quantitative indicator, objectively reflecting the degree of data deviation, overcoming the limitations of subjective judgment, and improving the scientific nature of anomaly determination. Operator CDR data anomalies are determined based on a similarity threshold. By using clear threshold standards, operator-side data anomalies are accurately screened, quickly locating the operator-side causes of data deviations, providing a clear direction for subsequent targeted processing such as appeals and corrections, and improving problem-solving efficiency.

[0021] In one optional implementation, the reasons for data usage deviation include abnormal local data usage data of the vehicle infotainment system and / or abnormal CDR data of the operator. Based on the reasons for the data usage deviation, the current data usage of the vehicle infotainment system corresponding to the target vehicle is corrected, including: if the reason for the data usage deviation is abnormal local data usage data of the vehicle infotainment system, then obtaining the baseline data usage data of the target vehicle; updating the current local data usage data of the vehicle infotainment system using the baseline data usage data; if the reason for the data usage deviation is abnormal CDR data of the operator, then obtaining the baseline data usage data of the target vehicle and the target data usage deviation; sending the baseline data usage data, the target data usage deviation, and the current CDR data of the operator to the target operator for appeal, and receiving the updated operator CDR data sent by the target operator, and updating the current operator CDR data based on the updated operator CDR data.

[0022] The vehicle-mounted data usage correction method provided in this application, if the data usage deviation is due to abnormal local data usage data of the vehicle-mounted system, obtains baseline data usage data and calls upon "gold standard" data that combines accuracy and authority to provide a reliable basis for local data correction, avoiding data deviation from actual consumption or non-compliance requirements after correction. The baseline data usage data is used to update the current local data usage of the vehicle-mounted system, directly and efficiently completing local data correction, quickly correcting abnormal records, ensuring the accuracy of data usage statistics on the vehicle-mounted system, and providing real data support for subsequent data usage management. If the data usage deviation is due to abnormal operator CDR data, the baseline data usage data and the target data usage deviation are obtained. The former provides a reference for the actual value, and the latter provides quantitative evidence of abnormalities. The combination of the two constructs a complete and credible evidence chain for operator appeals, improving the success rate of appeals. Data is submitted to the operator for appeal and updated data is received, prompting the operator to verify and correct erroneous billing data, resolving statistical deviations on the operator's side from the source, and ensuring the fairness of data usage billing. The current CDR data is synchronously updated based on the updated data. This enables unified calibration of operator data across vehicle-mounted systems and back-end systems, completing a closed loop for end-to-end data error correction and preventing new deviations caused by data inconsistencies.

[0023] Secondly, the present invention provides a vehicle infotainment system traffic usage error correction device, the device comprising:

[0024] The acquisition module is used to acquire the current vehicle-mounted data traffic usage corresponding to the target vehicle. The calculation module is used to calculate the target traffic usage deviation for the target vehicle based on the current vehicle traffic usage. The determination module is used to determine the cause of the traffic usage deviation based on the target traffic usage deviation; The error correction module is used to correct the current vehicle traffic usage of the target vehicle based on the cause of the traffic usage deviation.

[0025] Thirdly, the present invention provides a target vehicle, which includes a vehicle body and electronic equipment; wherein the electronic equipment includes a memory and a processor, which are interconnected, the memory stores computer instructions, and the processor executes the computer instructions to perform the vehicle traffic usage correction method of the first aspect or any corresponding embodiment described above.

[0026] Fourthly, the present invention provides a computer-readable storage medium storing computer instructions, which are used to cause a computer to execute the vehicle traffic usage error correction method of the first aspect or any corresponding embodiment described above.

[0027] Fifthly, the present invention provides a computer program product, including computer instructions, which are used to cause a computer to execute the vehicle traffic usage error correction method of the first aspect or any corresponding embodiment described above. Attached Figure Description

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

[0029] Figure 1 This is a schematic diagram of the first method for correcting vehicle traffic usage according to an embodiment of the present invention; Figure 2 This is a schematic diagram of the second process of the vehicle traffic usage correction method according to an embodiment of the present invention; Figure 3 This is a structural block diagram of the vehicle traffic usage correction device according to an embodiment of the present invention; Figure 4 This is a schematic diagram of the hardware structure of an electronic device according to an embodiment of the present invention. Detailed Implementation

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

[0031] It is understood that before using the technical solutions disclosed in the various embodiments of the present invention, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in the present invention and their authorization should be obtained in accordance with relevant laws and regulations through appropriate means.

[0032] The terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this invention, "a plurality of" means two or more, unless otherwise explicitly specified.

[0033] According to an embodiment of the present invention, a method for correcting vehicle traffic usage is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0034] This embodiment provides a method for correcting vehicle data usage errors, which can be used in electronic devices within a target vehicle. Figure 1 This is a flowchart of a vehicle infotainment system traffic usage error correction method according to an embodiment of the present invention, such as... Figure 1 As shown, the process includes the following steps: Step S101: Obtain the current vehicle traffic usage corresponding to the target vehicle.

[0035] Specifically, electronic devices can specify the current usage period (e.g., the morning peak period from 7:00 to 8:00 on May 20, 2024), the statistical scope (total application traffic / specific application traffic), and the network type (4G / 5G / Wi-Fi) to ensure that the data is consistent with the scenario dimensions for subsequent deviation calculations.

[0036] In one optional embodiment of this application, the current vehicle-mounted system traffic usage includes at least one of the following: current vehicle-mounted system local traffic data, current operator CDR data, and application layer API call data.

[0037] Optionally, the electronic device can use the vehicle-mounted traffic monitoring module to extract local traffic logs within the statistical period, summarize the number of bytes transmitted (upload + download), and obtain the vehicle-mounted local traffic data for the current vehicle traffic.

[0038] Optionally, the electronic device can estimate the application layer API call data based on the application layer API call record and the application type (e.g., playing a 30-minute high-definition video at a bitrate of 10Mbps would estimate a usage of approximately 225MB).

[0039] Optionally, the electronic device can obtain CDR data within the statistical period through the operator interface and extract the current operator CDR data (e.g., 55MB) of the target vehicle.

[0040] Step S102: Calculate the target traffic usage deviation for the target vehicle based on the current vehicle traffic usage.

[0041] Specifically, electronic devices can calculate the target traffic usage deviation for the target vehicle by subtracting the traffic usage baseline data from the current vehicle traffic usage.

[0042] This step will be explained in detail below.

[0043] Step S103: Determine the cause of the flow rate deviation based on the target flow rate deviation.

[0044] Specifically, electronic devices can determine the cause of traffic usage deviation based on the relationship between the target traffic usage deviation and the current vehicle traffic usage.

[0045] This step will be explained in detail below.

[0046] Step S104: Correct the current vehicle traffic usage of the target vehicle according to the cause of the traffic usage deviation.

[0047] Specifically, electronic devices can correct the current in-vehicle data usage of the target vehicle based on the cause of the data usage deviation.

[0048] This step will be explained in detail below.

[0049] The vehicle-mounted system traffic usage correction method provided in this application obtains the current vehicle-mounted system traffic usage for the target vehicle. This solidifies the foundation of correction data, ensuring comprehensive and accurate original data for subsequent calculations and judgments, avoiding deviations in subsequent processes due to missing or distorted data. Based on the current vehicle-mounted system traffic usage, the method calculates the target traffic usage deviation for the target vehicle, quantifying the degree of deviation in traffic statistics. This provides measurable quantitative indicators for determining "abnormality" and "cause of deviation," allowing subsequent judgments to move beyond subjective assumptions. Based on the target traffic usage deviation, the method identifies the cause of the traffic usage deviation. It accurately locates the source of error (vehicle-mounted system / operator / scenario fluctuations), avoiding blind correction and providing direction for targeted handling, thus improving correction efficiency. Based on the cause of the traffic usage deviation, the method corrects the current vehicle-mounted system traffic usage for the target vehicle. This corrects inaccurate traffic records, reduces additional costs for automakers, decreases user complaints, and optimizes traffic pool parameters to reduce future deviations. This technology solves the problem of inaccurate vehicle data usage statistics in existing technologies, resolves the discrepancy between the data usage billed by operators and the actual data usage of vehicle systems, protects the legitimate rights and interests of car manufacturers and users, and promotes the healthy and sustainable development of connected vehicle services.

[0050] This embodiment provides a method for correcting vehicle data usage errors, which can be used in electronic devices within a target vehicle. Figure 2 This is a flowchart of a vehicle infotainment system traffic usage error correction method according to an embodiment of the present invention, such as... Figure 2 As shown, the process includes the following steps: Step S201: Obtain the current vehicle traffic usage corresponding to the target vehicle.

[0051] Please refer to the above description of step S101 for details on this step, which will not be repeated here.

[0052] Step S202: Calculate the target traffic usage deviation for the target vehicle based on the current vehicle traffic usage.

[0053] Specifically, step S202 above may include the following steps: Step S2021: Obtain the baseline data of traffic usage corresponding to the target vehicle.

[0054] Specifically, the current vehicle data usage includes the current local data usage of the vehicle and the current carrier CDR data. Step S2021 above may include the following steps: Step a1: Using the current local traffic data of the vehicle's infotainment system as the observation value and the current CDR data of the operator as the reference value, construct the state equation; Specifically, electronic devices use the current in-vehicle local traffic data (L) as the observation value. The in-vehicle local traffic log records raw details such as timestamps, application identifiers, and the number of bytes transmitted. It is a direct record of every network activity and can accurately reflect the actual traffic consumption on the in-vehicle terminal. It is the most accurate first-hand data that is closest to the "real usage". Its core value lies in eliminating the indirect bias that may exist in operator statistics and providing a basis for "actual consumption perception" for the converged results.

[0055] The current operator's Call Detail Record (CDR) data (N) is used as a reference value. This data is automatically generated by the operator's network equipment and includes official records such as total data transmission volume, communication duration, and base station location. It possesses the authority endorsed by the operator and is the core basis for traffic billing within the industry. Its core value lies in providing an officially recognized reference standard for the convergence results, avoiding potential statistical loopholes in local data, and ensuring the compliance and credibility of the results.

[0056] The statistical caliber of dual-source data for electronic devices should be standardized (e.g., both should include protocol overhead, and the unit should be standardized to MB), and invalid data (e.g., missing log period records, base station traffic with abnormal jumps in CDR data) should be removed.

[0057] The core of the state equation is "scenario adaptation," eliminating inherent errors caused by scenario fluctuations (such as network type, application type, time of day, etc.) and making the data more closely match actual usage scenarios. Changes in traffic data are not random, but strongly correlated with scenarios (e.g., large fluctuations in 4G networks, unstable bitrates in video applications, network congestion during peak hours, etc.). The state equation quantifies this "scenario-data" correlation through a mathematical model, avoiding the use of fixed standards to measure traffic data under different scenarios.

[0058] Therefore, electronic devices focus on the three core dimensions of "network type + application type + time period" to extract the scenario combination of the current statistical period. For example: network type: 5G (stable transmission, small traffic statistics error); application type: navigation (real-time traffic updates, traffic consumption is strongly correlated with update frequency); time period: morning peak (7:00-8:00, high probability of network congestion, which may lead to fluctuations in traffic statistics); and finally form the scenario feature label: "5G + navigation application + morning peak".

[0059] Next, the electronic device sets input variables: key parameters corresponding to the scene feature labels are used as input, such as the navigation application update frequency (times / minute), the 5G network congestion coefficient during peak hours (0-1, the more severe the congestion, the closer the coefficient is to 1), and the application bitrate fluctuation range (the default for navigation is ±10%); and sets output variables: the theoretical trend of traffic data (including reasonable fluctuation range), that is, the theoretical traffic sequence after scene adaptation. Establish the mathematical expression: The general form of the state equation is as follows: ,in: This represents the theoretical flow rate at the current moment (within the statistical period). The current scene features parameters (e.g., congestion coefficient 0.3, update frequency 60 times / minute); The average traffic volume in the same historical scenario (e.g., the average traffic volume of 5G navigation scenario during the morning peak in history is 48MB). This is a scenario-specific fluctuation error term (determined based on historical data, such as allowing ±5% fluctuation during morning rush hour for navigation applications).

[0060] For example, assume the average traffic for the same historical scenario Given a congestion coefficient of 0.3, an update frequency of 60 times / minute, and a fluctuation error term of ±2.4MB, the state equation can be concretized as follows: (0.1 is the impact coefficient of update frequency on traffic), and the theoretical reasonable range of traffic for the current scenario is calculated to be 47.52MB-50.08MB.

[0061] Finally, output the theoretical traffic change curve after scenario adaptation, including the theoretical traffic value at each time point within the statistical period and the overall reasonable fluctuation range (such as 47.52MB-50.08MB in this example), to clarify the normal trend of traffic data change under the current scenario and avoid misjudging scenario-based fluctuations as data errors.

[0062] Step a2: Based on the state equation, construct the observation equation.

[0063] Specifically, electronic devices can use the theoretical traffic flow change curve output by the state equation as a basis, and take the mean or median of the theoretical traffic flow within the statistical period as the theoretical true value (T). For example, in this case, the reasonable range of theoretical traffic flow is 47.52MB-50.08MB, and the mean T=48.8MB is taken. Considering the inherent differences in attributes between the two sources of data, the optimization model is combined with the inherent characteristics of the data, and a characteristic correction coefficient is added to the deviation calculation. Specifically, the current vehicle-mounted local traffic flow data (L) has high statistical accuracy but may have application identifier confusion, so the correction coefficient α=0.95 (to reduce the impact of minor statistical loopholes); the current operator CDR data (N) has high authority but has update delays, so the correction coefficient β=0.98 (to reduce the deviation impact caused by delays).

[0064] The observation equation for constructing bias quantification using electronic equipment is based on correction coefficients and the theoretical true value (T). A bias calculation formula for dual-source data is established: Local data observation bias: ΔL = (L × α) Substitute T into the example data: (The negative sign indicates that L is lower than the theoretical true value, with a deviation of 1.3MB); Operator data observation bias: ΔN=(N×β) Substitute T into the example data: (The plus sign indicates that N is higher than the theoretical true value, with a deviation of 8.04MB).

[0065] This allows electronic devices to obtain specific deviation values ​​from dual-source data: local data deviation ΔL (e.g., -1.3MB) and carrier data deviation ΔN (e.g., 8.04MB). It clarifies the direction (higher / lower) and magnitude of deviation between the two types of data and the theoretical true values, providing accurate quantitative basis for subsequent weight allocation and dynamic correction.

[0066] Step a3: Based on the observation equation, calculate the baseline data of traffic flow usage corresponding to the target vehicle.

[0067] Specifically, the smaller the data source deviation, the higher the reliability and the higher the weight. Electronic devices can combine the scenario characteristics of the state equation (such as 5G network + navigation application + morning rush hour, the accuracy of local data statistics is less affected by the scenario) to comprehensively determine the weight. For example, the observation equation shows that the absolute value of ΔL (1.3MB) is much smaller than the absolute value of ΔN (8.04MB), indicating that the local data is closer to the theoretical true value. Therefore, the local data (L-ΔL) is assigned a weight of 0.6, and the operator data (N-ΔN) is assigned a weight of 0.4.

[0068] Electronic devices combine scenario trend adjustment deviation data with the theoretical traffic change curve output by the state equation to determine whether there is room for scenario-based correction of the current deviation. For example, the state equation shows that in the morning peak 5G navigation scenario, the theoretical traffic value shows a trend of "high in the first half and low in the second half". The local data (L=50MB) and the operator data (N=58MB) are both the total amount of the statistical period, and no additional adjustment of the deviation value is required (it has been incorporated into the scenario trend through the state equation). If the scenario is "video application + peak period", the state equation shows that the bitrate fluctuation causes the traffic to be higher in the first half. ΔL and ΔN can be corrected by time segment before summarizing.

[0069] Electronic devices can input the corrected data source and weights to calculate the baseline traffic data (B) using a weighted formula: Formula: For example,

[0070] The final integer B ≈ 51MB.

[0071] The electronic device obtains baseline traffic usage data (B), such as 51MB in the example. This result retains the accuracy of the vehicle's local data, which is "close to actual consumption" (L is 51.3MB after correction, with a high weighting), and also incorporates the compliance of the operator's CDR data, which is "official and authoritative" (N is 49.96MB after correction, providing a compliance reference). At the same time, it eliminates problems such as scene fluctuations and statistical errors through state equations and observation equations, becoming the "gold standard" for subsequent comprehensive deviation calculations and traffic anomaly judgments.

[0072] Step S2022: Based on the current vehicle traffic usage and traffic usage benchmark data, calculate the target traffic usage deviation for the target vehicle.

[0073] Specifically, the current vehicle infotainment system traffic usage includes at least one of the following: current local vehicle infotainment system traffic data, current carrier CDR data, and application layer API call data; step S2022 above may include the following steps: Step b1: Calculate the first absolute value deviation between the current vehicle-mounted local traffic data and the traffic usage baseline data.

[0074] Specifically, the electronic device can subtract the baseline data of data usage from the current local data traffic of the vehicle's infotainment system to obtain a first difference. Then, the absolute value of the first difference is calculated to obtain the first absolute value deviation.

[0075] For example, (|| represents the absolute value symbol, indicating that the calculated result is non-negative). Where L is the current local traffic data of the vehicle's infotainment system, B is the baseline traffic usage data, and DL is the first absolute value deviation. For example, The first absolute deviation (DL), such as 1MB in the example, reflects the deviation between the vehicle's local traffic data and the traffic usage baseline data. The smaller the value, the closer the local data is to the baseline value.

[0076] Step b2: Calculate the second absolute value deviation between the current operator CDR data and the traffic usage benchmark data.

[0077] Specifically, electronic devices can subtract the baseline data of data usage from the current operator's CDR data to obtain a second difference. Then, the absolute value of the second difference is calculated to obtain the second absolute value deviation.

[0078] For example, (|| represents the absolute value symbol, indicating that the calculation result is non-negative). Where N is the current operator's CDR data, B is the traffic usage baseline data, and DN is the second absolute value deviation. For example, The second absolute deviation (DN), such as 7MB in the example, reflects the deviation between the operator's CDR data and the traffic usage baseline data. The smaller the value, the closer the operator's data is to the baseline value.

[0079] Step b3: Calculate the third absolute value deviation between the application layer API call data and the traffic usage baseline data.

[0080] Specifically, electronic devices can use application-layer API calls to subtract the baseline data of traffic usage to obtain a third difference. Then, the absolute value of the third difference is calculated to obtain the third absolute value deviation.

[0081] For example, (|| represents the absolute value symbol, indicating that the calculated result is non-negative). Where A is the application layer API call data, B is the traffic usage baseline data, and DA is the third absolute value deviation. For example, The third absolute deviation (DA), such as 0MB in the example, reflects the deviation between application-layer scenario-based extrapolation data and baseline traffic usage data. The smaller the value, the more accurate the scenario-based extrapolation.

[0082] Step b4: Calculate the target flow rate deviation corresponding to the target vehicle based on the first absolute value deviation, and / or the second absolute value deviation, and / or the third absolute value deviation.

[0083] Optionally, the electronic device can determine the first absolute value deviation as the target flow usage deviation corresponding to the target vehicle. Optionally, the electronic device can determine the second absolute value deviation as the target flow usage deviation corresponding to the target vehicle. Optionally, the electronic device can determine the third absolute value deviation as the target flow usage deviation corresponding to the target vehicle. Optionally, the electronic device can also obtain the weight information of the first and second absolute value deviations, and then perform a weighted sum based on the weight information of the first and second absolute value deviations to obtain the target flow usage deviation corresponding to the target vehicle. Optionally, the electronic device can also obtain the weight information of the second and third absolute value deviations, and then perform a weighted sum based on the weight information of the second and third absolute value deviations to obtain the target flow usage deviation corresponding to the target vehicle. Optionally, the electronic device can also obtain the weight information of the first and third absolute value deviations, and then perform a weighted sum based on the weight information of the first and third absolute value deviations to obtain the target flow usage deviation corresponding to the target vehicle.

[0084] Optionally, the electronic device can also acquire the weight information corresponding to the first absolute value deviation, the second absolute value deviation, and the third absolute value deviation, respectively. Then, based on the weight information corresponding to the first absolute value deviation, the second absolute value deviation, and the third absolute value deviation, a weighted sum is performed to obtain the target flow usage deviation corresponding to the target vehicle.

[0085] For example, in-vehicle local data (DL): weight W L =0.4 (high stability); Carrier CDR data (DN): Weight W N =0.4 (High Authority); Application Layer API Data (DA): Weight W A =0.2 (High scenario relevance). Perform weighted comprehensive calculation: Calculation formula: D=W L ×DL+W N ×DN+W A ×DA; an example D = 0.4×1 + 0.4×7 + 0.2×0 = 0.4 + 2.8 + 0 = 3.2MB.

[0086] Step S203: Determine the cause of the flow rate deviation based on the target flow rate deviation.

[0087] Specifically, step S203 above may include the following steps: Step S2031: Obtain the current traffic usage scenario characteristics corresponding to the target vehicle.

[0088] The current traffic usage scenario characteristics include network type, application type, and current time period.

[0089] Specifically, electronic devices can obtain the network type accessed by the vehicle's infotainment system within the statistical period from the vehicle's traffic monitoring module or operator CDR data. Optional values ​​include 4G, 5G, and Wi-Fi (note: Wi-Fi generally does not involve operator billing discrepancies and is only used as a scenario reference), with 5G being an example. Electronic devices can extract the main application type (i.e., the application with the highest proportion) consuming traffic within the statistical period from the current local traffic data of the vehicle's infotainment system or application layer API call data. Common types include navigation, video, text communication (such as WeChat text), and system update applications, with navigation being an example. Electronic devices can divide traffic usage into time periods based on time characteristics, primarily into peak periods (e.g., morning peak 7:00-9:00, evening peak 17:00-19:00), off-peak periods (e.g., 9:00-17:00), and low-peak periods (e.g., 0:00-7:00), with morning peak (7:00-8:00) being an example.

[0090] Electronic devices can combine three-dimensional features into unified scene labels, facilitating subsequent threshold matching and cause investigation, and generating current traffic usage scene feature labels. An example is "5G + Navigation + Morning Peak". Electronic devices remove invalid scene features (such as abnormal records of frequent network type switching or application type misidentification logs) to ensure the accuracy of scene features.

[0091] Step S2032: Determine the absolute deviation threshold range corresponding to the target traffic usage deviation based on the characteristics of the current traffic usage scenario.

[0092] In one alternative implementation, the electronic device can pre-establish a mapping table between "network type + application type + time period" and absolute deviation threshold range based on historical data (as shown in Table 1 below, unit: MB).

[0093] Table 1. Mapping Table between "Network Type + Application Type + Time Period" and Absolute Deviation Threshold Range

[0094] Electronic devices match scene feature labels with a mapping table to extract the corresponding absolute deviation threshold range. In the example, the threshold range matched for "5G + navigation + morning rush hour" is 2MB~5MB. If the historical deviation data of the target vehicle in the same scene differs significantly from the preset threshold (e.g., the deviation is high because the vehicle frequently uses navigation in congested areas), the threshold range can be fine-tuned based on the vehicle's personalized historical data (e.g., adjusting 2~5MB in the example to 3~6MB) to improve the adaptability of the threshold.

[0095] In another optional implementation, the electronic device extracts the basic absolute deviation threshold for each dimension according to preset threshold rules for each dimension. For example, the basic absolute deviation threshold for the network type dimension is: for a 4G network, the basic Dth value is 50MB; for a 5G network, the basic Dth value is 30MB. The basic absolute deviation threshold for the application type dimension is supplemented with preset basic values ​​for different application types, combined with example rules: video stream basic Dth = 30MB, text stream basic Dth = 5MB, navigation application basic Dth = 20MB. This basic value is the default value during off-peak hours (the rule is "video stream Dth is set to 40MB during peak hours and 30MB during off-peak hours"). Video stream application: Dth basic value = 30MB (default value during off-peak hours); text stream application: Dth basic value = 5MB; navigation application: Dth basic value = 20MB (default value during off-peak hours).

[0096] The adjustment factor rule for the time period dimension is that Dth is increased by 30% during peak hours and during off-peak hours. Therefore: the adjustment factor for peak hours = 1.3 (i.e., base value × 1.3); the adjustment factor for off-peak hours = 1.0 (i.e., the base value remains unchanged). Example (continuing from the scenario in step 1): the base value of Dth for 5G networks = 30MB; the base value of Dth for video streaming applications = 30MB; the adjustment factor for peak hours = 1.3.

[0097] Because the threshold rules of different dimensions have a linkage priority (the time period dimension is a core linkage dimension that dynamically adjusts the base value of the application type / network type dimension), it is necessary to calculate the preliminary absolute deviation threshold by taking the base value of the application type + network type as the core and combining it with the adjustment coefficient of the time period dimension. Specifically, the adjustment coefficient of the time period dimension takes priority on the base Dth value of the application type (the original example clearly states that "the Dth of the video stream is set to 40MB during peak hours and 30MB during off-peak hours", that is, the base value of the video stream is 30MB × 1.3 ≈ 39MB, which is rounded to 40MB).

[0098] For navigation applications, in addition to the adjustment coefficient for the time period, the time period rules of the navigation application itself must also be considered. However, the absolute deviation threshold (Dth) is still based on "base value × time period coefficient", while the relative deviation threshold (Rth) is distinguished separately. The base value of Dth for the network type serves as the upper limit constraint for the threshold (that is, the adjusted threshold cannot exceed the base value of Dth for the corresponding network type. If it does, the base value of Dth for the network type will be used as the upper limit).

[0099] Electronic devices can calculate the linkage Dth value for application type + time period: linkage Dth value = application type Dth base value × time period adjustment coefficient; if linkage Dth value ≤ the corresponding network type Dth base value, then the final preliminary Dth value = linkage Dth value; if linkage Dth value > the corresponding network type Dth base value, then the final preliminary Dth value = the corresponding network type Dth base value (to avoid the threshold exceeding the stability limit of the network type after application and time period adjustment).

[0100] Example (continuing the scenario from step 1): Video stream + peak hour linkage Dth value = 30MB × 1.3 = 39MB (rounded to 40MB); the base Dth value of 5G network is 30MB, 40MB > 30MB, so the final initial Dth value = 30MB (constrained by the upper limit of the threshold of 5G network).

[0101] To make threshold judgment more flexible (avoiding rigid judgment based on a single value), electronic devices may need to set a threshold range based on the initial Dth value (the minimum value is 80% of the initial Dth value, the maximum value is the initial Dth value, and it can also be adjusted according to actual needs), and finally obtain the absolute deviation threshold range corresponding to the target flow usage deviation.

[0102] For example, the minimum threshold range = the initial Dth value × 0.8 (i.e., the lower limit of the minimum allowable deviation, ensuring that slight deviations will not be misjudged); the maximum threshold range = the initial Dth value (i.e., the upper limit of the maximum allowable deviation, if exceeded, it is judged as abnormal); the final absolute deviation threshold range = [minimum threshold value, maximum threshold value].

[0103] Step S2033: Compare the target flow rate deviation with the absolute deviation threshold range.

[0104] Specifically, the electronic device can compare the target flow rate deviation with the absolute deviation threshold range. If the target flow rate deviation is greater than the minimum value of the absolute deviation threshold range but less than the maximum value of the absolute deviation threshold range, it is determined to be a normal deviation, and no further investigation is needed.

[0105] If the target traffic usage deviation is greater than the maximum value of the threshold range, or the target traffic usage deviation is less than the minimum value of the threshold range, it is determined to be an abnormal deviation, and subsequent steps need to be performed.

[0106] Step S2034: If the target traffic usage deviation exceeds the absolute deviation threshold range, the cause of the traffic usage deviation is determined based on the characteristics of the current traffic usage scenario.

[0107] In an optional implementation, the current vehicle infotainment system traffic usage includes the current local traffic data of the vehicle infotainment system, and the reasons for traffic usage deviation include abnormal local traffic data of the vehicle infotainment system. The step S2034 above, "determine the reasons for traffic usage deviation based on the characteristics of the current traffic usage scenario", may include the following steps: Step c1: Based on the characteristics of the current traffic usage scenario, search the preset historical traffic database for historical vehicle-mounted local traffic data that matches the characteristics of the current traffic usage scenario.

[0108] The preset historical traffic database is pre-built by the electronic device and contains historical traffic data of the target vehicle (or vehicles of the same model / with the same usage habits). Each data entry needs to be associated with key information such as scenario feature tags (network type + application type + time period), vehicle-mounted local traffic data, and statistical period. The statistical period of the current vehicle-mounted local traffic data (e.g., 1 hour, 1 day) is consistent with the statistical period of the historical vehicle-mounted local traffic data (1 hour for example).

[0109] Electronic devices can retrieve multiple historical in-vehicle local traffic data points (such as 20 data points from the same scenario in the past 30 days) from a preset historical traffic database based on the characteristics of the current traffic usage scenario. The electronic devices can calculate the mean / median / reasonable range of these historical in-vehicle local traffic data points (for example, the mean of the 20 historical in-vehicle local traffic data points is 45MB, denoted as the historical in-vehicle local traffic reference value H). L The electronic device outputs historical in-vehicle local traffic data (or its statistical reference value) that is consistent with the characteristics of the current traffic usage scenario. An example is H. L =45MB.

[0110] Step c2: Calculate the first similarity between the current vehicle infotainment system local traffic data and the historical vehicle infotainment system local traffic data.

[0111] Specifically, the current local traffic data of the vehicle system is denoted as L. current (The example is 70MB, which is significantly different from the historical average); the historical in-vehicle system local traffic reference value is denoted as H. L (Exemplary H) L =45MB).

[0112] Electronic devices can choose a similarity calculation method. For example, electronic devices can use a similarity formula derived from relative error (with values ​​ranging from 0 to 1, where 1 represents complete similarity and 0 represents complete dissimilarity) to calculate the first similarity: The calculation formula is as follows: .

[0113] Alternatively, the electronic device can also use the cosine similarity method to calculate the cosine similarity between the current vehicle system local traffic data and the historical vehicle system local traffic data, with the result also between 0 and 1.

[0114] Step c3: If the first similarity is less than the first preset similarity threshold, then the cause of the traffic usage deviation is determined to be abnormal local traffic data of the vehicle system.

[0115] Specifically, the first preset similarity threshold can be a normal lower limit of similarity derived from historical data statistics (e.g., 70%). If the first similarity is less than the first preset similarity threshold, it indicates that the current data deviates from the historical pattern of the same scenario, and the reason for the deviation in traffic usage is determined to be abnormal local traffic data of the vehicle system. The first preset similarity threshold can be set according to the actual business scenario and historical data, and is usually set to 70% (0.7) (it can also be fine-tuned according to vehicle usage habits, such as 80% for vehicles with long-term stable usage).

[0116] In an optional implementation, the current vehicle data usage includes the current operator CDR data, and the reasons for data usage deviation include abnormal operator CDR data. The step S2034 above, "determine the reasons for data usage deviation based on the characteristics of the current data usage scenario," may further include the following steps: Step c4: Based on the characteristics of the current traffic usage scenario, search for historical operator CDR data that are consistent with the characteristics of the current traffic usage scenario from the preset historical traffic database.

[0117] Specifically, the preset historical traffic database is pre-built by electronic devices and contains historical traffic data of the target vehicle (or vehicles of the same model / with the same usage habits). Each data entry needs to be associated with key information such as scenario feature tags (network type + application type + time period), vehicle-mounted local traffic data, and statistical period. The statistical period of the current vehicle-mounted local traffic data (e.g., 1 hour, 1 day) is consistent with the statistical period of the historical vehicle-mounted local traffic data (1 hour for example).

[0118] Electronic devices can search for historical operator CDR data (such as 20 data entries from the same scenario in the past 30 days) that are consistent with the characteristics of the current traffic usage scenario from a preset historical traffic database based on the characteristics of the current traffic usage scenario.

[0119] Step c5: Calculate the second similarity between the current operator's CDR data and the historical operator's CDR data.

[0120] Specifically, the current operator's CDR data: denoted as N current (Example: 90MB); Historical Carrier CDR Reference Value: denoted as H N =48MB.

[0121] Electronic devices can choose a similarity calculation method. For example, electronic devices can use a similarity formula derived from relative error (with values ​​ranging from 0 to 1, where 1 represents complete similarity and 0 represents complete dissimilarity) to calculate the second similarity: The calculation formula is as follows: .

[0122] Alternatively, electronic devices can also use the cosine similarity method to calculate the cosine similarity between the current operator's CDR data and the historical operator's CDR data, with the result also ranging from 0 to 1.

[0123] Step c6: If the second similarity is less than the second preset similarity threshold, then the cause of the traffic usage deviation is determined to be abnormal operator CDR data.

[0124] Specifically, the second preset similarity threshold can be a normal lower limit of similarity derived from historical data statistics (e.g., 75%). If the second similarity is less than the second preset similarity threshold, it indicates that the current data deviates from the historical pattern of the same scenario, and the reason for the traffic usage deviation is determined to be abnormal operator CDR data. The second preset similarity threshold can be set according to the actual business scenario and historical data, and is usually set to 75% (0.76) (it can also be fine-tuned according to vehicle usage habits, such as 80% for vehicles with long-term stable usage).

[0125] Step S204: Correct the current vehicle traffic usage of the target vehicle according to the cause of the traffic usage deviation.

[0126] Specifically, the reasons for the deviation in data usage include abnormal local data traffic data of the vehicle system and / or abnormal CDR data of the operator. The above step S204 may include the following steps: Step S2041: If the reason for the deviation in traffic usage is that the local traffic data of the vehicle system is abnormal, then obtain the traffic usage benchmark data corresponding to the target vehicle; update the current local traffic data of the vehicle system using the traffic usage benchmark data.

[0127] Specifically, electronic devices can first detect abnormal current vehicle-mounted local traffic data (L... current =70MB), the cause of the anomaly (such as application identifier obfuscation), statistical period and other information are backed up to the vehicle's local log and backend database to facilitate subsequent source tracing and problem analysis (to avoid losing abnormal data records after correction).

[0128] Then, replace the abnormal current vehicle infotainment system local traffic data with the traffic usage baseline data. Replace the current vehicle infotainment system local traffic data for the current statistical period in the vehicle infotainment system local traffic statistics module with the traffic usage baseline data, including: the traffic usage value displayed on the vehicle infotainment system (such as the traffic statistics page in the vehicle infotainment system settings); the original records in the vehicle infotainment system local traffic log (such as traffic details stored by timestamp); and the traffic data synchronized from the vehicle infotainment system to the background (ensuring that the cloud data is consistent with the local data).

[0129] Next, the electronic device repairs the root cause of local data anomalies (optional optimization). To prevent similar anomalies from recurring, the root cause of the anomaly needs to be addressed. If the anomaly is caused by application identifier confusion: update the vehicle's application identification algorithm and optimize the matching rules between application package names and traffic attribution; if the anomaly is caused by local log recording failure: restart the traffic statistics service or repair the log storage module. The electronic device then verifies the update results again, checking whether the traffic data of each module in the vehicle's local system has been uniformly updated to the traffic usage baseline data (45MB), and confirming that the data statistics caliber is consistent with the previous one (e.g., both are upload + download traffic, unit is MB), ensuring that the error correction is effective.

[0130] Step S2042: If the reason for the traffic usage deviation is abnormal operator CDR data, then obtain the traffic usage baseline data and target traffic usage deviation corresponding to the target vehicle.

[0131] Step S2043: Send the traffic usage baseline data, target traffic usage deviation, and current operator CDR data to the target operator for appeal, and receive the updated operator CDR data sent by the target operator, and update the current operator CDR data based on the updated operator CDR data.

[0132] Specifically, if the deviation in data usage is due to abnormal CDR data from the operator, the electronic device can calculate the relative deviation ratio (R) using the following formula: (That is, the relative deviation between the current operator's CDR data and the baseline data of traffic usage, reflecting the severity of the deviation).

[0133] Example 1: B = 40MB, N current =46MB, (Slight deviation); Example 2: B = 40MB, N current =50MB, (Serious deviation); If there is no behavior-based billing (the vehicle log shows no network behavior within the statistical period, but the CDR data shows traffic consumption), it is directly judged as a serious deviation.

[0134] If 10% ≤ R ≤ 20%, it is determined to be a minor deviation (e.g., 15% in Example 1); if R > 20%, or there is no behavior billing, it is determined to be a serious deviation (e.g., 25% in Example 2).

[0135] Electronic devices can collect user data in the current area (such as a city / base station coverage area) based on communication connections with other devices. If more than 30% of users experience the same type of CDR data anomaly (such as base station miscounting traffic), a batch anomaly is triggered, with a higher priority than the deviation level of a single user.

[0136] Thus, the electronic device can obtain the deviation level judgment result (such as "minor deviation", "serious deviation", "batch anomaly"). Example 1 is "minor deviation" and Example 2 is "serious deviation".

[0137] If the deviation level is determined to be a slight deviation (10%≤R≤20%), then the electronic device acquires the baseline data (B) of data usage, the target data usage deviation (D), and the current operator CDR data (N). current The current vehicle data usage (L) is used to correct the current operator's CDR data and make a preliminary determination of the cause of the deviation (such as "normal protocol overhead" or "statistical error caused by network fluctuations"). The above data and the cause of the deviation are recorded in the system log as a basis for subsequent tracing.

[0138] If the deviation level is determined to be a serious deviation (R>20% or no behavior billing), the electronic device can collect and organize key evidence data for the appeal to ensure the materials are complete and verifiable, including: Baseline traffic usage data (B): Retrieve the baseline traffic usage data for the corresponding statistical period as a reference for the actual traffic value (Example: B=48MB); Target traffic usage deviation (D): Retrieve the previously calculated target traffic usage deviation as quantitative evidence of abnormal operator CDR data (Example: D=42MB, i.e., the deviation range between the current CDR data and the baseline traffic usage data); Current operator CDR data (N current ): Retrieve locally stored original CDR data from the operator (including information such as statistical period, traffic volume, and base station location; example: N) current =90MB); Electronic devices can submit appeal requests through the in-vehicle infotainment system's built-in operator appeal interface, operator's app, customer service hotline, or the operator's interface connected to the backend server. Appeal content should include: the target vehicle's identifier (e.g., phone number, vehicle VIN), statistical period, and core evidence data (B=48MB, D=42MB, N...). current =90MB), and a complaint (requesting the operator to verify and correct the CDR data); For example, submit a complaint to China Mobile stating, "License plate number ×××, statistical period May 20, 2024, 7:00-8:00, the CDR data provided by your company is 90MB, which deviates from the actual data usage benchmark of 48MB by 42MB. Please verify and correct."

[0139] If more than 30% of users experience similar CDR data anomalies, the electronic device can aggregate the anomaly data by region, requiring the operator to process it in batches. The electronic device can aggregate regional anomaly data: regional scope (e.g., "City A, District B, XX base station coverage area"), percentage of anomaly users (e.g., 35%), baseline traffic usage data (B) for all anomaly users, target traffic usage deviation (D), and current operator CDR data (N). current Summary table. Commonalities analysis of similar deviations in electronic devices (e.g., "all due to miscalculation of traffic during handover at this base station"), then generate a regional appeal report: attaching "bulk correction request + traffic compensation request" (requiring the operator to compensate for traffic pool quota). Materials / reports corresponding to the deviation level (simplified correction materials, complete appeal report, regional appeal materials).

[0140] Upon receiving the complaint, the target operator will verify the original data in its billing system (such as base station traffic records and user behavior patterns) based on the submitted evidence. Once the CDR data is confirmed to be abnormal, the operator will correct the data and generate updated operator CDR data (N). update Electronic devices can receive updated data from operators through complaint channels. For example, the operator might provide feedback N. update =48MB (consistent with the baseline data for data usage), along with a data correction explanation (e.g., "Upon verification, the base station data usage was incorrectly counted and has been corrected"). Updating the current operator's CDR data based on updated operator CDR data is similar to local data updates, requiring completion of the entire data update and verification process: Backing up the original abnormal CDR data: Back up the current abnormal operator's CDR data (90MB), appeal records, operator correction explanations, etc., to both the local machine and the backend database for easy traceability. Replacing with the updated CDR data: Replace all current operator's CDR data stored locally, displayed on the vehicle's infotainment system, and synchronized to the backend with N. update =48MB, ensuring data consistency across the entire link. Verify the update results by checking whether the updated data is consistent with the data reported by the operator and matches the baseline data of traffic usage, confirming that the operator's error correction is complete.

[0141] The vehicle-mounted system traffic usage correction method provided in this application constructs a state equation using the current local traffic data of the vehicle-mounted system as the observed value and the operator's CDR data as the reference value. It quantifies the impact of scenario characteristics such as network type, application type, and time period on traffic data, eliminating inherent errors caused by scenario fluctuations. This ensures that the calculation of traffic usage benchmark data closely matches the actual vehicle usage scenario, avoiding the use of fixed standards to measure traffic data under different scenarios. Based on the state equation, an observation equation is constructed to accurately quantify the deviation between the local vehicle-mounted system data, the operator's CDR data, and the theoretical true value after scenario adaptation. This provides a quantitative basis for subsequent dynamic correction, avoids subjective judgment errors, and ensures the objectivity of traffic usage benchmark data calculation. Based on the observation equation, the traffic usage benchmark data is calculated. By dynamically weighting and fusing dual-source data, a benchmark value that balances the accuracy of actual vehicle-mounted system consumption and the authority of operator data is generated. This avoids the limitations of a single data source and provides a reliable "gold standard" for subsequent deviation calculation and anomaly detection. The first absolute deviation is calculated to quantify the deviation between the local vehicle-mounted system traffic data and the traffic usage benchmark data, clarifying the degree of difference between the local data and the "gold standard," providing a quantitative basis for locating local data anomalies. The second absolute deviation is calculated. Measuring the deviation between operator CDR data and baseline traffic usage data provides a quantitative indicator for judging the accuracy of operator billing data and the existence of statistical errors. Calculating the third absolute value deviation further assesses the fit between application-layer extrapolated data and baseline traffic usage data, reflecting the accuracy of scenario-based traffic models and improving the coverage of multi-dimensional deviation analysis. Target traffic usage deviation is calculated based on these three types of deviations. Through weighted or combined calculations of multi-source deviations, an indicator that comprehensively reflects the overall traffic statistics deviation is obtained, avoiding the one-sidedness of deviations from a single data source, and providing objective and comprehensive quantitative support for subsequent anomaly detection and cause localization.

[0142] Then, the characteristics of the current traffic usage scenario are obtained, and core dimensions of network, application, and time period information are extracted to provide a scenario-based basis for subsequent threshold setting and cause localization, avoiding a uniform judgment standard that is detached from the actual usage scenario. The absolute deviation threshold range corresponding to the target traffic usage deviation is determined, and a reasonable deviation range is matched based on scenario characteristics, ensuring that the threshold judgment fits the traffic fluctuation characteristics of different scenarios and reducing the probability of normal scenario fluctuations being misjudged as abnormal. The target traffic usage deviation is compared with the absolute deviation threshold range. Abnormal deviations are quickly screened out through quantitative comparison, clarifying the necessity of subsequent cause investigation and improving the objectivity and efficiency of deviation judgment. If the target traffic usage deviation exceeds the absolute deviation threshold range, the cause of the traffic usage deviation is determined based on the characteristics of the current traffic usage scenario. The scope of cause investigation is narrowed by combining scenario characteristics, accurately locating the deviation source strongly related to the scenario (such as base station switching errors during peak hours, video application bitrate fluctuation errors), avoiding blind investigation and improving the accuracy of cause localization.

[0143] Historical in-vehicle local traffic data is searched and matched based on scene features. Historical data from the same scene is used as a reference benchmark to avoid interference from data from different scenes, ensuring the rationality and comparability of subsequent similarity comparisons. The first similarity score between the current and historical local data is calculated, quantifying the degree of fit between the current data and historical data from the same scene. This transforms the judgment of "whether it is abnormal" into a measurable numerical indicator, overcoming the limitations of subjective experience. In-vehicle local data anomalies are determined based on similarity thresholds. Abnormal data is filtered out through clear threshold standards, accurately locating the in-vehicle side causes of traffic deviations, providing a clear direction for subsequent targeted error correction, and improving the efficiency and accuracy of deviation cause identification.

[0144] Historical carrier CDR data is searched and matched based on scene features, anchoring historical carrier data in the same scene as a reference benchmark to ensure scene consistency of the compared data and avoid misjudgment due to scene differences, providing a reasonable reference basis for carrier data anomaly determination. A second similarity score is calculated between current and historical carrier CDR data. The fit between current carrier data and historical data in the same scene is converted into a quantitative indicator, objectively reflecting the degree of data deviation, overcoming the limitations of subjective judgment, and improving the scientific nature of anomaly determination. Carrier CDR data anomalies are determined based on similarity thresholds. Clear threshold standards accurately screen out data anomalies on the carrier side, quickly locating the carrier-side causes of traffic deviations, providing a clear direction for subsequent targeted handling such as appeals and error corrections, and improving problem-solving efficiency.

[0145] If the data usage deviation is due to abnormal local data usage data in the vehicle's infotainment system, baseline data usage is obtained. This data, considered both accurate and authoritative, serves as the "gold standard," providing a reliable basis for local data correction and preventing corrected data from deviating from actual consumption or failing to meet compliance requirements. The baseline data usage is used to update the current local data usage data in the vehicle's infotainment system, directly and efficiently correcting local data errors, quickly resolving abnormal records, ensuring the accuracy of data usage statistics on the vehicle's infotainment system, and providing real data support for subsequent data usage management. If the data usage deviation is due to abnormal operator CDR data, baseline data usage and the target data usage deviation are obtained. The former provides a reference for the actual value, while the latter provides quantitative evidence of the anomaly. The combination of both builds a complete and credible evidence chain for operator appeals, improving the success rate of appeals. Data is submitted to the operator's appeal and updated data is received, prompting the operator to verify and correct erroneous billing data, resolving statistical deviations on the operator's side at the source, and ensuring the fairness of data billing. The current CDR data is updated synchronously based on the updated data. This achieves unified calibration of operator data on the vehicle's infotainment system and the backend system, completing a closed loop of end-to-end data error correction and preventing new deviations caused by data inconsistencies.

[0146] This embodiment also provides a vehicle traffic usage correction device, which is used to implement the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can refer to a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0147] This embodiment provides a vehicle infotainment system traffic usage correction device, such as... Figure 3 As shown, it includes: The acquisition module 301 is used to acquire the current vehicle traffic usage of the target vehicle. The calculation module 302 is used to calculate the target traffic usage deviation for the target vehicle based on the current vehicle traffic usage. The determination module 303 is used to determine the cause of the flow usage deviation based on the target flow usage deviation; The error correction module 304 is used to correct the current vehicle traffic usage of the target vehicle based on the cause of the traffic usage deviation.

[0148] The vehicle data usage correction device provided in this embodiment of the invention can execute the vehicle data usage correction method provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects for executing the method. Further functional descriptions of the above modules and units are the same as in the corresponding embodiments described above, and will not be repeated here.

[0149] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention.

[0150] The following is a detailed reference. Figure 4 The diagram illustrates a structural schematic suitable for implementing an electronic device according to embodiments of the present invention. The electronic device may include a processor (e.g., a central processing unit, graphics processor, etc.) 01, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 02 or a program loaded from a memory 08 into a random access memory (RAM) 03. The RAM 03 also stores various programs and data required for the operation of the electronic device. The processor 01, ROM 02, and RAM 03 are interconnected via a bus 04. An input / output (I / O) interface 05 is also connected to the bus 04.

[0151] Typically, the following devices can be connected to I / O interface 05: input devices 06 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 07 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; memory devices 08 including, for example, magnetic tapes, hard disks, etc.; and communication devices 09. Communication device 09 allows electronic devices to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 4 Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown, and more or fewer devices may be implemented or have instead.

[0152] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device 09, or installed from a memory 08, or installed from a ROM 02. When the computer program is executed by the processor 01, it performs the functions defined in the vehicle traffic usage error correction method of the embodiments of the present invention.

[0153] Figure 4 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments of the present invention.

[0154] This invention also provides a computer-readable storage medium. The methods described above according to embodiments of the invention can be implemented in hardware or firmware, or implemented as computer code that can be recorded on a storage medium, or implemented as computer code downloaded via a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and then stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code. When the software or computer code is accessed and executed by the computer, processor, or hardware, the vehicle traffic usage error correction method shown in the above embodiments is implemented.

[0155] A portion of this invention can be applied as a computer program product, such as computer program instructions, which, when executed by a computer, can invoke or provide the methods and / or technical solutions according to the invention through the operation of the computer. Those skilled in the art will understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, installation package files, etc. Correspondingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executing the instructions, or the computer compiling the instructions and then executing the corresponding compiled program, or the computer reading and executing the instructions, or the computer reading and installing the instructions and then executing the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to a computer.

[0156] Although embodiments of the invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the invention, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A method for correcting vehicle data usage errors, characterized in that, The method includes: Obtain the current in-vehicle data usage for the target vehicle; Based on the current vehicle infotainment system traffic usage, calculate the target traffic usage deviation corresponding to the target vehicle; Based on the deviation from the target flow rate, determine the cause of the flow rate deviation; Based on the cause of the traffic usage deviation, the current vehicle-mounted system traffic usage corresponding to the target vehicle is corrected.

2. The method according to claim 1, characterized in that, The step of calculating the target traffic usage deviation for the target vehicle based on the current vehicle infotainment system traffic usage includes: Obtain the baseline data of traffic usage corresponding to the target vehicle; Based on the current vehicle traffic usage and the traffic usage benchmark data, the target traffic usage deviation corresponding to the target vehicle is calculated.

3. The method according to claim 2, characterized in that, The current vehicle infotainment system traffic usage includes the current local traffic data of the vehicle infotainment system and the current carrier CDR data. Obtaining the traffic usage baseline data corresponding to the target vehicle includes: Using the current in-vehicle local traffic data as the observation value and the current operator CDR data as the reference value, a state equation is constructed; Based on the state equation, an observation equation is constructed; Based on the observation equation, the baseline data of traffic flow usage corresponding to the target vehicle is calculated.

4. The method according to claim 2, characterized in that, The current vehicle infotainment system traffic usage includes at least one of the following: current vehicle infotainment system local traffic data, current carrier CDR data, and application layer API call data. The step of calculating the target traffic usage deviation for the target vehicle based on the current vehicle traffic usage and the traffic usage benchmark data includes: Calculate the first absolute value deviation between the current vehicle-mounted local traffic data and the traffic usage baseline data; Calculate the second absolute value deviation between the current operator CDR data and the traffic usage benchmark data; Calculate the third absolute value deviation between the application layer API call data and the traffic usage baseline data; Based on the first absolute value deviation, and / or the second absolute value deviation, and / or the third absolute value deviation, the target flow usage deviation corresponding to the target vehicle is calculated.

5. The method according to claim 1, characterized in that, The step of determining the cause of the flow usage deviation based on the target flow usage deviation includes: Obtain the current traffic usage scenario characteristics corresponding to the target vehicle; the current traffic usage scenario characteristics include network type, application type, and current time period; Based on the characteristics of the current traffic usage scenario, determine the absolute deviation threshold range corresponding to the target traffic usage deviation; Compare the target flow rate deviation with the absolute deviation threshold range; If the target traffic usage deviation exceeds the absolute deviation threshold range, the cause of the traffic usage deviation is determined based on the characteristics of the current traffic usage scenario.

6. The method according to claim 5, characterized in that, The current vehicle infotainment system traffic usage includes the current local traffic data of the vehicle infotainment system. The reasons for the traffic usage deviation include abnormal local traffic data of the vehicle infotainment system. Determining the reasons for the traffic usage deviation based on the characteristics of the current traffic usage scenario includes: Based on the characteristics of the current traffic usage scenario, search the preset historical traffic database for historical vehicle-mounted local traffic data that matches the characteristics of the current traffic usage scenario; Calculate the first similarity between the current in-vehicle infotainment system local traffic data and the historical in-vehicle infotainment system local traffic data; If the first similarity is less than the first preset similarity threshold, then the reason for the deviation in traffic usage is determined to be abnormal local traffic data of the vehicle system.

7. The method according to claim 5, characterized in that, The current vehicle data usage includes the current carrier CDR data, and the reasons for the data usage deviation include abnormal carrier CDR data. Determining the reasons for the data usage deviation based on the characteristics of the current data usage scenario includes: Based on the characteristics of the current traffic usage scenario, search for historical operator CDR data that are consistent with the characteristics of the current traffic usage scenario from a preset historical traffic database; Calculate the second similarity between the current operator CDR data and the historical operator CDR data; If the second similarity is less than the second preset similarity threshold, then the reason for the traffic usage deviation is determined to be abnormal operator CDR data.

8. The method according to claim 2, characterized in that, The reasons for the data usage deviation include abnormal local data usage data of the vehicle infotainment system and / or abnormal CDR data of the carrier. The step of correcting the current data usage of the vehicle infotainment system corresponding to the target vehicle based on the reasons for the data usage deviation includes: If the reason for the deviation in data usage is abnormal local data usage data of the vehicle infotainment system, then obtain the baseline data of data usage corresponding to the target vehicle; update the current local data usage data of the vehicle infotainment system using the baseline data of data usage. If the reason for the traffic usage deviation is that the operator's CDR data is abnormal, then obtain the traffic usage baseline data and the target traffic usage deviation corresponding to the target vehicle; The traffic usage baseline data, the target traffic usage deviation, and the current operator CDR data are sent to the target operator for appeal, and the updated operator CDR data sent by the target operator is received. The current operator CDR data is then updated based on the updated operator CDR data.

9. A vehicle traffic usage error correction device, characterized in that, The device includes: The acquisition module is used to acquire the current vehicle-mounted data traffic usage corresponding to the target vehicle. The calculation module is used to calculate the target traffic usage deviation corresponding to the target vehicle based on the current vehicle traffic usage. The determination module is used to determine the cause of the traffic usage deviation based on the target traffic usage deviation; The error correction module is used to correct the current vehicle-mounted traffic usage corresponding to the target vehicle based on the cause of the traffic usage deviation.

10. A target vehicle, characterized in that, The target vehicle includes a vehicle body and electronic devices; wherein, the electronic devices include: a memory and a processor, the memory and the processor being communicatively connected to each other, the memory storing computer instructions, and the processor executing the computer instructions to perform the vehicle traffic usage correction method according to any one of claims 1 to 9.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing the computer to execute the vehicle traffic usage error correction method according to any one of claims 1 to 9.

12. A computer program product, characterized in that, Includes computer instructions, which are used to cause a computer to execute the vehicle traffic usage correction method according to any one of claims 1 to 9.

Images