A vehicle data uploading method, device, storage medium and program product

CN122990826APending Publication Date: 2026-10-27ZHEJIANG GEELY HLDG GRP CO LTD +1
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202611463164.7
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2026-09-20
Publication Date
2026-10-27

AI Technical Summary

Technical Problem

[0002]在车辆的研发测试阶段,研发人员需要根据车辆上传的车辆数据评估车辆性能并排查缺陷,然而,车辆在测试过程中产生的车辆数据极其庞大,根本无法实时地将车辆在测试过程中产生的全量车辆数据上传至云端,因此,车端采用何种上传策略成为当前亟需解决的问题

Benefits of technology

[0029]根据本申请一个或多个实施例的第四方面,提供一种计算机可读存储介质,其上存储有计算机指令,该指令被处理器执行时实现如上述第一方面的实施例中所述方法的步骤。

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122990826A_ABST
    Figure CN122990826A_ABST
Patent Text Reader

Abstract

The application provides a vehicle data uploading method and device, a storage medium and a program product. The method can include: in response to detecting a data uploading trigger event, performing change point detection on characteristic values of collected full-amount vehicle data to obtain a change point detection result; determining a target time window according to the change point detection result, the target time window covering an occurrence time corresponding to the detected change point; obtaining full-amount vehicle data in the target time window, and uploading the obtained data. This way can accurately lock the key data segment containing the event evolution process, filter out invalid stable data, save network bandwidth and storage cost, and still retain complete data details to meet subsequent data analysis requirements. Moreover, the uploaded full-amount vehicle data is highly time-effective, which can improve the efficiency and flexibility of research and development testing.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of vehicle technology, and more particularly to a method, device, storage medium, and program product for uploading vehicle data. Background Technology

[0002] During the vehicle research and development testing phase, R&D personnel need to evaluate vehicle performance and troubleshoot defects based on the vehicle data uploaded by the vehicle. However, the vehicle data generated during the testing process is extremely large, making it impossible to upload all the vehicle data generated during the testing process to the cloud in real time. Therefore, deciding on the appropriate upload strategy for the vehicle has become an urgent problem to be solved. Summary of the Invention

[0003] This application provides a method, device, storage medium, and program product for uploading vehicle data to address the shortcomings of related technologies.

[0004] According to a first aspect of one or more embodiments of this application, a method for uploading vehicle data is provided, the method comprising: In response to the detection of a data upload trigger event, change point detection is performed on the feature values ​​of the collected full vehicle data to obtain the change point detection results; Based on the change point detection results, a target time window is determined, which covers the occurrence time corresponding to the detected change point; Obtain all vehicle data within the target time window and upload the obtained data.

[0005] In some possible implementations, determining the target time window based on the change point detection results includes: Based on the change point detection results, determine the change initiation critical point and the change termination critical point; The target time window is determined based on the occurrence times of the change initiation critical point and the change termination critical point.

[0006] In some possible implementations, the change initiation critical point is the earliest change point or the Mth stable point before the earliest change point; and / or, the change termination critical point is the latest change point or the Nth stable point after the latest change point. Wherein, M is any positive integer, and N is any positive integer.

[0007] In some possible implementations, determining the target time window based on the occurrence times of the change initiation critical point and the change termination critical point includes: The starting time of the target time window is obtained by shifting the occurrence time of the change initiation critical point forward by a first time duration. The termination time of the target time window is obtained by shifting the occurrence time of the change termination threshold backward by a second time period.

[0008] In some possible implementations, the full vehicle data includes multiple types of vehicle data; Determining the target time window based on the occurrence times of the change initiation critical point and the change termination critical point includes: In response to the fact that the change start threshold and change end threshold of the feature values ​​corresponding to each type of vehicle data meet the preset distribution conditions, the full amount of vehicle data is divided into at least two vehicle data groups, and each vehicle data group includes at least one type of vehicle data. For each vehicle data group, the target time window corresponding to the vehicle data group is determined based on the detection results of the change points of the feature values ​​of the vehicle data in the vehicle data group.

[0009] In some possible implementations, dividing the full vehicle data into at least two vehicle data groups includes any of the following: Based on the importance of various vehicle data to the data upload triggering event, the full vehicle data is divided into at least two vehicle data groups; Based on the distribution characteristics of the start and end points of change corresponding to various vehicle data on the time axis, the full amount of vehicle data is divided into at least two vehicle data groups.

[0010] In some possible implementations, the method further includes uploading the feature values ​​of the full vehicle data.

[0011] In some possible implementations, before uploading the feature values ​​of the full vehicle data, the method further includes: The feature values ​​of the full vehicle data are subjected to dimensionality reduction processing.

[0012] In some possible implementations, the feature values ​​for uploading the full vehicle data include: According to the preset upload cycle, the feature values ​​extracted from the full amount of vehicle data collected in the current cycle are uploaded periodically.

[0013] In some possible implementations, uploading the feature values ​​of the full vehicle data includes: uploading the feature values ​​of the full vehicle data to the cloud; The method further includes: receiving a data collection instruction sent from the cloud, the data collection instruction being used to instruct the uploading of all vehicle data within a first time window; wherein, the first time window is determined by the cloud based on the analysis of received feature values.

[0014] In some possible implementations, the feature value includes at least one of the following: Eigenvalues ​​of statistical characteristics; Eigenvalues ​​of time-domain features; Eigenvalues ​​of frequency domain features; The characteristic values ​​of the rate of change feature; Eigenvalues ​​of correlation features.

[0015] In some possible implementations, the preset data upload trigger event includes at least one of the following: an event of an anomaly occurring on the vehicle side, an event of entering the target scene, and receiving a data collection instruction issued by the cloud.

[0016] According to a second aspect of one or more embodiments of this application, a vehicle data uploading device is provided, the device comprising: The change point detection unit is used to detect change points in the feature values ​​of the collected full vehicle data in response to the detection of a data upload trigger event, and obtain the change point detection results. A window determination unit is used to determine a target time window based on the change point detection results, wherein the target time window covers the occurrence time corresponding to the detected change point; The data upload unit is used to acquire all vehicle data within the target time window and upload the acquired data.

[0017] In some possible implementations, the window determination unit is used to determine the change start critical point and the change end critical point based on the change point detection results; and to determine the target time window based on the occurrence time of the change start critical point and the occurrence time of the change end critical point.

[0018] In some possible implementations, the change initiation critical point is the earliest change point or the Mth stable point before the earliest change point; and / or, the change termination critical point is the latest change point or the Nth stable point after the latest change point. Wherein, M is any positive integer, and N is any positive integer.

[0019] In some possible implementations, the window determination unit is used to shift the occurrence time of the change start threshold forward by a first time period to obtain the start time of the target time window; and shift the occurrence time of the change end threshold backward by a second time period to obtain the end time of the target time window.

[0020] In some possible implementations, the full vehicle data includes multiple types of vehicle data; The window determination unit is used to divide the full vehicle data into at least two vehicle data groups in response to the fact that the change start threshold and change end threshold of the feature values ​​corresponding to each type of vehicle data meet the preset distribution conditions. Each vehicle data group includes at least one type of vehicle data. For each vehicle data group, the target time window corresponding to the vehicle data group is determined according to the change point detection results of the feature values ​​of the vehicle data in the vehicle data group.

[0021] In some possible implementations, the window determining unit is configured to perform any of the following: Based on the importance of various vehicle data to the data upload triggering event, the full vehicle data is divided into at least two vehicle data groups; Based on the distribution characteristics of the start and end points of change corresponding to various vehicle data on the time axis, the full amount of vehicle data is divided into at least two vehicle data groups.

[0022] In some possible implementations, the data uploading unit is also used to upload the feature values ​​of the full vehicle data.

[0023] In some possible implementations, the device further includes: The dimensionality reduction unit is used to perform dimensionality reduction processing on the feature values ​​of the full vehicle data.

[0024] In some possible implementations, the data uploading unit is used to periodically upload feature values ​​extracted from the full amount of vehicle data collected within the current period, according to a preset uploading cycle.

[0025] In some possible implementations, the data uploading unit is used to upload the feature values ​​of the full vehicle data to the cloud; The device further includes: The receiving unit is used to receive data collection instructions sent from the cloud, which instruct the upload of all vehicle data within a first time window; wherein the first time window is determined by the cloud based on the received feature values.

[0026] In some possible implementations, the feature value includes at least one of the following: Eigenvalues ​​of statistical characteristics; Eigenvalues ​​of time-domain features; Eigenvalues ​​of frequency domain features; The characteristic values ​​of the rate of change feature; Eigenvalues ​​of correlation features.

[0027] In some possible implementations, the preset data upload trigger event includes at least one of the following: an event of an anomaly occurring on the vehicle side, an event of entering the target scene, and receiving a data collection instruction issued by the cloud.

[0028] According to a third aspect of one or more embodiments of this application, an electronic device is provided, comprising: processor; Memory used to store processor-executable instructions; The processor executes the executable instructions to implement the method described in the embodiments of the first aspect above.

[0029] According to a fourth aspect of one or more embodiments of this application, a computer-readable storage medium is provided having computer instructions stored thereon that, when executed by a processor, implement the steps of the method as described in the embodiments of the first aspect above.

[0030] According to a fifth aspect of one or more embodiments of this application, a computer program product is provided, having a computer program or instructions stored thereon, which, when executed by a processor, implement the steps of the method as described in the embodiments of the first aspect above.

[0031] The vehicle data uploading method provided in this application, upon detecting a data upload trigger event, performs change point detection on the feature values ​​of all vehicle data and dynamically determines a target time window covering the time when the change point occurs. Only the full vehicle data within this target time window is uploaded. This method can accurately identify key data segments containing the event evolution process, filter out invalid and stable data, save network bandwidth and storage costs, and retain complete data details to meet subsequent data analysis needs. Furthermore, the uploaded full vehicle data has high timeliness, which can improve the efficiency and flexibility of R&D testing.

[0032] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0033] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0034] Figure 1 This is a schematic flowchart of a method for uploading vehicle data provided in an exemplary embodiment.

[0035] Figure 2 This is a schematic flowchart of a method for uploading vehicle data provided in an exemplary embodiment.

[0036] Figure 3 This is a schematic diagram illustrating the structure of an electronic device in an exemplary embodiment.

[0037] Figure 4 This is a block diagram illustrating a vehicle data uploading device in an exemplary embodiment.

[0038] Figure 5 This is a block diagram illustrating a vehicle data uploading device in an exemplary embodiment. Detailed Implementation

[0039] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0040] It should be noted that the steps of the corresponding methods in other embodiments are not necessarily performed in the order shown and described in this application. In some other embodiments, the methods may include more or fewer steps than those described in this application. Furthermore, a single step described in this application may be broken down into multiple steps in other embodiments; and multiple steps described in this application may be combined into a single step in other embodiments.

[0041] During the vehicle research and development testing phase, R&D personnel need to evaluate vehicle performance and identify defects based on the vehicle data uploaded by the vehicle. Currently, the main strategies for uploading vehicle data are as follows: (1) Cloud-based configuration: The cloud sends a data collection command to the vehicle, which carries the conditions for triggering data collection (such as detecting a specific fault code, or the vehicle speed exceeding a speed threshold). When the vehicle detects that the conditions are met, it records and uploads the vehicle data for a period of time before and after the current moment. However, this method of uploading data based on a fixed time window is not intelligent enough. In practical applications, if the fixed time window is set too small, the uploaded vehicle data may not cover the entire process of vehicle status changes, resulting in the loss of key causal information and making it impossible for R&D personnel to accurately perform root cause analysis. Conversely, if the fixed time window is set too large, although it can ensure the integrity of the data, it inevitably introduces a large amount of irrelevant data, resulting in a waste of network bandwidth and cloud storage resources.

[0042] (2) Vehicle-side local processing and uploading method: After collecting vehicle data, the vehicle-side performs preliminary processing on the collected vehicle data locally (such as filtering, statistics, or diagnosis), and only uploads the processing results of the vehicle data (such as average fuel consumption, abnormal readings of sensor A, etc.). Although this method can effectively save network bandwidth and cloud storage resources, it also loses the details of the original vehicle data. These details are key for R&D personnel to conduct root cause analysis, problem reproduction, and performance optimization. Therefore, this uploading method cannot meet the data analysis needs.

[0043] (3) External Data Recorder Full-Process Recording Method: An external data recorder is connected to the vehicle; during the test, the external data recorder records all vehicle data throughout the process. Although this method can obtain complete vehicle data, the amount of vehicle data generated during the test is extremely large, which means that the data recorder cannot upload the vehicle data in real time during the recording process. The recorded vehicle data can only be obtained after the test is completed by the staff physically removing the data recorder or the memory in the data recorder from the vehicle. This post-testing acquisition mode results in poor timeliness of data acquisition. At the same time, because it is impossible to acquire and analyze vehicle data in real time during the test, it is difficult for R&D personnel to adjust strategies in a timely manner based on the anomalies that occur during the test, and to continuously reproduce the fault to obtain more detailed information, which reduces the efficiency and flexibility of R&D testing.

[0044] Based on this, this application provides a method for uploading vehicle data. When a data upload trigger event is detected, the method detects changes in the feature values ​​of all vehicle data and dynamically determines a target time window covering the time when the changes occur. Only the full vehicle data within this target time window is uploaded. This method can accurately identify key data segments containing the event evolution process, filter out invalid and stable data, save network bandwidth and storage costs, and retain complete data details to meet subsequent data analysis needs. Furthermore, the uploaded full vehicle data has high timeliness, which can improve the efficiency and flexibility of R&D testing.

[0045] The vehicle data uploading method provided in this application can be executed by an electronic device. In some embodiments, the electronic device may include, but is not limited to, any type of terminal such as an in-vehicle terminal, a data recorder, or a smartphone. The in-vehicle terminal may include, but is not limited to, any one or more in-vehicle modules such as a vehicle, a processing unit deployed on the vehicle, an intelligent driving unit, or a positioning unit. This application embodiment is merely an illustrative example of the execution subject and does not limit it.

[0046] The following describes one or more embodiments of this application in detail.

[0047] Figure 1 A flowchart illustrating a method for uploading vehicle data as an exemplary embodiment. Figure 1 As shown, the method may include the following steps: S101. In response to the detection of a data upload trigger event, change point detection is performed on the feature values ​​of the collected full vehicle data to obtain the change point detection results.

[0048] The data upload trigger event refers to the event that triggers the execution of the vehicle data upload method provided in this application embodiment. In some embodiments, the data upload trigger event can be a predefined trigger event. For example, the cloud sends a data collection instruction containing preset trigger conditions (such as a specific fault code, a specific vehicle speed threshold, etc.) to the vehicle. When the vehicle detects that the preset trigger conditions are met, it executes the above step S101. The data upload trigger event is the event that meets the preset trigger conditions.

[0049] In some embodiments, the data upload trigger event can also be an event autonomously identified by the vehicle-side through analysis of local data. For example, the vehicle-side can analyze real-time collected vehicle data, and when a specific event (such as an abnormal event, an event entering a target scene, etc.) is identified, the aforementioned step S101 is executed. This data upload trigger event is the identified specific event. While relying solely on specific trigger conditions issued by the cloud for data upload only allows for the upload of known, definable events, this method of autonomous event identification by the vehicle-side can effectively capture unknown, complex, and sporadic software logic problems or cross-controller collaborative faults, improving the coverage of data feedback and facilitating troubleshooting and performance optimization by R&D personnel.

[0050] Abnormal events can be any event that indicates a deviation of the vehicle's operating status from the normal baseline. For example, a certain type of vehicle data exceeding the reasonable range for that type of vehicle data, navigation lag, black screen, undefined state or memory overflow of software variables within the domain controller, addition or change of diagnostic fault codes, interruption or verification failure of sensor data, etc.

[0051] The target scenario can be a scenario or condition that is valuable for vehicle performance evaluation or research and development. For example, emergency braking scenario, automatic parking scenario, scenario of passing through complex intersections, OTA (Over-The-Air Technology) scenario, system power-on / off state switching scenario, etc.

[0052] It should be noted that the embodiments in this application are merely illustrative examples of abnormal events and target scenarios, and are not intended to limit them. In practical applications, the corresponding abnormal events or target scenarios can be flexibly configured according to testing needs or R&D goals.

[0053] In summary, the data upload trigger event can include at least one of the following: an event where an anomaly occurs on the vehicle side, an event where the vehicle enters the target scene, and an event that meets the preset trigger conditions in the data collection command issued from the cloud.

[0054] For example, when the vehicle detects a Flag (trigger point), the vehicle data uploading method provided in this application embodiment is executed. The Flag can be sent from the cloud or automatically generated locally. This application embodiment does not limit the circumstances under which the cloud generates and sends the Flag; the process of generating and sending the Flag from the cloud is illustrated by the following two examples: (1) When the cloud analyzes big data and finds common abnormal trends in vehicles of the same model, it generates a flag and sends it to the corresponding vehicle. For example, if vehicles A, B and C in the test fleet are of the same model, and vehicles A and B both have fault D, the cloud determines that there is a potential common defect in this model of vehicles. It then generates a flag and sends it to vehicle C, which has not yet experienced fault D, to instruct vehicle C to focus on monitoring vehicle data related to fault D, thereby capturing potential abnormal states in advance.

[0055] (2) When R&D personnel perform active calibration operations or issue remote diagnostic commands through the cloud, a Flag is generated and sent to the corresponding vehicle.

[0056] Calibration can be viewed as the process by which R&D personnel manually modify or set the operating parameters and monitoring rules of the vehicle controller to test a certain function of the vehicle. For example, during the R&D testing phase, R&D personnel need to test the stability of the battery under low temperature and high current discharge. R&D personnel can perform active calibration operations through the cloud, setting "battery temperature below a first value and discharge current above a second value" as a preset trigger condition, generating a flag, and sending a data acquisition command carrying the preset trigger condition and flag to the vehicle under test.

[0057] Remote diagnostics can be seen as the cloud proactively sending diagnostic commands to the vehicle when abnormal signs appear but no fault is detected. For example, if the cloud detects that the vehicle's battery temperature is slightly high but has not yet triggered a fault, developers can trigger a remote diagnostic command through the cloud, setting "battery temperature higher than the third value and duration greater than the fourth value" as a preset trigger condition, generating a flag, and sending a data collection command carrying the preset trigger condition and flag to the vehicle.

[0058] This application does not limit the method of automatically generating Flags locally, but only uses the following case as an example to illustrate the process of automatically generating Flags locally: The vehicle runs an analytics engine that analyzes real-time vehicle data and generates a flag when any of the following conditions are detected: (1) Data for a certain type of vehicle is outside its reasonable range.

[0059] This reasonable range can be a threshold set based on the vehicle's physical characteristics or historical normal operating conditions. For example, the vehicle speed change rate is greater than 100 km / (hours*seconds).

[0060] (2) Software variables inside the domain controller are in an undefined state or have a memory overflow.

[0061] This situation typically indicates a low-level logic error or memory management anomaly in the vehicle software during operation. Such software failures are somewhat sporadic. When this situation is detected, a flag is generated to trigger data location and uploading, allowing developers to trace the software's operating environment before and after the failure and analyze its cause.

[0062] (3) Diagnostic Trouble Code (DTC) is added or changed.

[0063] When a new or changed DTC is detected, it indicates that a vehicle malfunction has occurred. At this time, a flag is generated to trigger data location and uploading, which can accurately pinpoint the data related to the malfunction.

[0064] (4) Sensor data interruption or verification failure.

[0065] When the sensor sends the collected sensor data to the vehicle controller, a verification code is usually attached to the end of the data to prevent transmission errors or loss due to electromagnetic interference or other reasons. After the vehicle controller receives the data sent by the sensor, it will recalculate a verification code. If the new verification code is different from the one attached to the end of the data, the verification will be considered a failure. In other words, a verification failure means that the data is corrupted.

[0066] It should be noted that the embodiments in this application are merely illustrative of the circumstances under which a Flag is automatically generated locally, and are not intended to limit the scope of such generation.

[0067] In some embodiments, the analysis engine encapsulates multiple preset rules to determine whether an anomaly has occurred at the vehicle end. In some embodiments, the analysis engine may include an anomaly detection model to determine whether an anomaly has occurred at the vehicle end. Analyzing vehicle data using a neural network model to determine whether an anomaly has occurred at the vehicle end can capture the complex nonlinear coupling relationships between different types of vehicle data, enabling more accurate anomaly identification.

[0068] Full vehicle data refers to the complete set of raw data collected during vehicle operation, without sampling or deletion. This full vehicle data comprehensively and accurately reflects the underlying physical and software logical states of the vehicle during operation. For example, this full vehicle data includes, but is not limited to: raw messages from the Controller Area Network (CAN) bus, raw messages from the Local Interconnect Network (LIN) bus, raw messages from the Ethernet bus, key software variables within each domain controller, raw sensor signals, and diagnostic messages, etc.

[0069] In this embodiment, a feature value refers to a numerical value extracted or calculated based on full vehicle data, used to characterize the vehicle's operating state or data distribution pattern. In some possible implementations, the feature value includes at least one of the following: (1) Eigenvalues ​​of statistical features.

[0070] The characteristic value of this statistical feature is a numerical value obtained by statistically processing vehicle data, used to describe the overall distribution of the vehicle data. For example, this statistical feature includes, but is not limited to, mean, median, standard deviation, maximum value, minimum value, and variance. This application embodiment is merely an illustrative example of statistical features and does not limit their application.

[0071] In some embodiments, the characteristic value of the statistical feature can be calculated from the vehicle data using a statistical formula.

[0072] (2) Eigenvalues ​​of time-domain features.

[0073] The eigenvalues ​​of time-domain features are used to represent the characteristics of vehicle data changing over time, and can be used to identify transient shocks or abnormal fluctuations in vehicle data. For example, these time-domain features include, but are not limited to, root mean square (RMS), peak factor, impulse factor, and margin factor. The embodiments in this application are merely illustrative examples of time-domain features and are not intended to limit their application.

[0074] In some embodiments, the eigenvalues ​​of the time-domain feature can be calculated from the vehicle data using time-domain signal analysis formulas.

[0075] (3) Eigenvalues ​​of frequency domain features.

[0076] The eigenvalues ​​of frequency domain features are obtained after frequency domain transformation of vehicle data. They describe the energy distribution of vehicle data in the frequency domain and can be used to identify mechanical resonance phenomena or periodic external interference in the vehicle system. These frequency domain features include, but are not limited to, spectral centroid frequency, mean square frequency, and band energy ratio. The embodiments in this application are merely illustrative examples of frequency domain features and are not intended to limit their application.

[0077] In some embodiments, the eigenvalues ​​of the frequency domain feature can be obtained by statistical analysis after performing a Fourier transform on the vehicle data.

[0078] (4) Characteristic values ​​of the rate of change.

[0079] The eigenvalues ​​of the rate of change feature are used to describe the drastic change of vehicle data over time and can be used to detect abrupt events. For example, the rate of change feature includes, but is not limited to, the maximum slope of change and the cumulative absolute value of signal change. The embodiments in this application are merely illustrative examples of the rate of change feature and are not intended to limit its application.

[0080] In some embodiments, the eigenvalues ​​of the rate of change feature can be obtained by calculating the difference sequence of vehicle data and performing statistical analysis on the difference sequence.

[0081] (5) Eigenvalues ​​of correlation features.

[0082] The eigenvalues ​​of correlation features are used to describe the degree of association or coupling between different types of vehicle data, and can be used to identify abnormal coupling between different types of vehicle data. For example, the correlation feature includes, but is not limited to, the correlation coefficient with neighboring vehicle data and the correlation coefficient with a standard template. This application's embodiments are merely illustrative of correlation features and do not limit their application.

[0083] Among them, neighboring vehicle data refers to other types of vehicle data that are correlated with the currently analyzed vehicle data in terms of time series or logical control. A standard template is used to represent the data distribution patterns of vehicles under normal operating conditions.

[0084] In some embodiments, the eigenvalues ​​of the correlation feature can be obtained by correlation analysis algorithms (such as Pearson correlation coefficient calculation or cross-correlation analysis).

[0085] In this embodiment, vehicle data is collected continuously; therefore, the extracted feature values ​​of the vehicle data typically exist in the form of a sequence. A feature value sequence can be viewed as a collection of multiple feature values ​​arranged in chronological order. Each feature value in this sequence corresponds to a sampling point on the time axis, thus reflecting the pattern of vehicle operating status changes over time. The change point detection performed in this embodiment is actually the detection of this feature value sequence.

[0086] In this embodiment, change point detection refers to the process of analyzing a sequence of feature values ​​to identify locations where significant changes occur in the data distribution characteristics. This embodiment does not limit the specific algorithm used for change point detection; it is merely illustrative. In some embodiments, a method based on statistical hypothesis testing can be used, such as the CUSUM (Cumulative Sum Control Chart) algorithm. In some embodiments, a method based on Bayesian inference can be used, such as the BOCPD (Bayesian Online Change Point Detection) algorithm. In some embodiments, a method based on penalized likelihood estimation can be used, such as the PELT (Pruned Exact Linear Time) algorithm. In some embodiments, a machine learning-based method can also be used. For example, change point detection can be performed using a change point detection model. In some embodiments, a custom judgment rule can also be used for change point detection. For example, when a feature value exceeds the fifth value of the corresponding mean, the sampling point corresponding to that feature value is determined to be a change point.

[0087] The change point detection result is used to indicate whether each sampling point in the feature value sequence is a change point or a stationary point. The specific content of the change point detection result is not limited in this embodiment. For example, the change point detection result includes the timestamp corresponding to the change point. For example, the change point detection result includes the state label of each sampling point in the feature value sequence, the state label being used to characterize whether the corresponding sampling point is a change point or a stationary point.

[0088] In some embodiments, there may be an accumulation process before an anomaly occurs on the vehicle side. These potential problems may initially manifest as slight drifts or increased fluctuations in feature values, but have not yet reached the level to trigger an anomaly. To discover such hidden anomalies or early trends in the accumulation phase, and thus obtain data fragments containing the evolution process before the anomaly occurs, change point detection can be performed based on locally cached full vehicle data. Specifically, change point detection on the feature values ​​of the collected full vehicle data includes: acquiring the feature values ​​of the locally cached full vehicle data, and performing change point detection on the acquired feature values.

[0089] For example, a local cache can store all vehicle data during the vehicle testing process. For instance, the local cache can employ a FIFO (First In First Out) circular buffer to store all vehicle data from the most recent period (e.g., the past 30 minutes). By using a circular buffer mechanism, the most recently relevant and analytically valuable vehicle data can be continuously retained within limited on-vehicle storage resources, thus providing sufficient data for change point detection.

[0090] In some embodiments, to reduce computational load, the change point detection may be performed only on vehicle data that is valuable for recent analysis. Specifically, performing change point detection on the feature values ​​of all collected vehicle data includes: performing change point detection on the feature values ​​of all vehicle data within a second time window.

[0091] The second time window can be a preset fixed time window, such as the most recent 10 minutes, the most recent 20 minutes, the most recent 30 minutes, etc.; or it can be a window whose size is dynamically adjusted according to the vehicle's operating status. This embodiment of the application does not impose any restrictions on the second time window. By detecting changes in the feature values ​​of all vehicle data within the second time window, the amount of computation can be effectively reduced and the response speed can be improved.

[0092] In some embodiments, the full vehicle data includes multiple types of vehicle data. For each type of vehicle data, at least one feature value can be extracted. Change point detection is performed on the feature values ​​of the collected full vehicle data to obtain change point detection results. This may include: performing change point detection on each feature value of each type of feature data to obtain multiple initial change point detection results; fusing and deduplicating the multiple initial change point detection results to obtain the final change point detection result.

[0093] S102. Based on the change point detection results, determine the target time window, which covers the occurrence time corresponding to the detected change point.

[0094] This application embodiment aims to extract data segments containing change information from the timeline by determining the target time window covering the change points. This not only eliminates useless stable data, reduces the amount of data processing in subsequent steps, and saves network bandwidth and cloud storage resources, but also ensures that the extracted data segments can completely preserve the evolution process of the event when the vehicle experiences an abnormal event, providing high-value data samples for subsequent data analysis.

[0095] In one possible implementation, to ensure that the target time window fully covers the occurrence times corresponding to each change point, the target time window can be determined based on the change initiation critical point and the change termination critical point. Specifically, determining the target time window based on the change point detection results includes: determining the change initiation critical point and the change termination critical point based on the change point detection results; and determining the target time window based on the occurrence times of the change initiation critical point and the change termination critical point.

[0096] Among them, the starting critical point of change is used to represent the sampling point where the feature value changes from a stable state to a changing state; the ending critical point of change is used to represent the sampling point where the feature value changes from a changing state to a stable state.

[0097] In some embodiments, the starting critical point of the change is the earliest change point or the Mth stable point before the earliest change point. Here, M is any positive integer. Since the earliest change point is the first change point in the change point detection results, all sampling points before this change point are stable points. Therefore, the Mth stable point before the earliest change point is also the Mth sampling point before the earliest change point.

[0098] In some embodiments, the termination point of the change is the latest change point or the Nth stable point after the latest change point. Here, N is any positive integer. Since the latest change point is the last change point in the change point detection results, all sampling points after this change point are stable points. Therefore, the Nth stable point after the latest change point is also the Nth sampling point after the latest change point.

[0099] For example, the starting critical point of the change is the earliest change point, and the ending critical point of the change is the latest change point. For example, the starting critical point of the change is the earliest change point, and the ending critical point of the change is the first stable point after the latest change point. For example, the starting critical point of the change is the first stable point before the earliest change point, and the ending critical point of the change is the first stable point after the latest change point.

[0100] In some embodiments, a target time window is determined based on the occurrence times of the change initiation critical point and the change termination critical point, including: using the occurrence time of the change initiation critical point as the start time of the target time window; and using the occurrence time of the change termination critical point as the end time of the target time window. This method can accurately extract data segments that have changed, minimizing redundant data.

[0101] However, considering that feature changes may not be instantaneous, there may be subtle precursor fluctuations before the change initiation threshold, or brief recovery oscillations after the change termination threshold. To further ensure that the target time window can cover more comprehensive contextual information, in some embodiments, determining the target time window based on the occurrence times of the change initiation threshold and the change termination threshold may include: shifting the occurrence time of the change initiation threshold forward by a first duration to obtain the start time of the target time window; and shifting the occurrence time of the change termination threshold backward by a second duration to obtain the end time of the target time window.

[0102] The first duration can be any duration, such as 2 seconds, 3 seconds, 5 seconds, etc. The second duration can be any duration, such as 1 second, 2 seconds, etc. The first duration and the second duration can be the same or different. In some embodiments, the first duration and the second duration are set by the user (such as a researcher). In some embodiments, the first duration and the second duration are empirical values. The embodiments in this application are merely illustrative examples of the first duration and the second duration and are not intended to limit them.

[0103] For example, based on the change point detection results, the earliest change point and the latest change point are determined. The occurrence time of the earliest change point is shifted forward by 2 seconds to obtain the start time of the target time window; the occurrence time of the latest change point is shifted backward by 1 second to obtain the end time of the target time window.

[0104] S103. Obtain all vehicle data within the target time window and upload the obtained data.

[0105] In other words, the original data segments corresponding to the time periods where features change significantly are uploaded in their entirety without undergoing lossy compression processing such as downsampling. By uploading the original data, it is possible to ensure that cloud providers or R&D personnel obtain complete details of vehicle operation, providing high-quality data support for subsequent data analysis.

[0106] The destination for data uploads can be the cloud, a local edge computing node, or a developer's computer. The specific upload location can be flexibly set according to actual business needs; this application does not impose any restrictions on this.

[0107] In some embodiments, data can be compressed during upload, and this compression can be either lossy or lossless. In one instance, the type of vehicle data can be determined based on whether it should be compressed lossily or losslessly. For example, lossless compression can be used for important types of vehicle data, while lossy compression can be used for less important types.

[0108] In some embodiments, when uploading data, the priority of the data upload triggering event can be determined, and the data corresponding to each data upload triggering event can be uploaded sequentially according to the priority. In some embodiments, lossy compression or lossless compression can also be selected for the uploaded data based on the priority.

[0109] The vehicle data uploading method provided in this application, upon detecting a data upload trigger event, performs change point detection on the feature values ​​of all vehicle data and dynamically determines a target time window covering the time when the change point occurs. Only the full vehicle data within this target time window is uploaded. This method can accurately identify key data segments containing the event evolution process, filter out invalid and stable data, save network bandwidth and storage costs, and retain complete data details to meet subsequent data analysis needs. Furthermore, the uploaded full vehicle data has high timeliness, which can improve the efficiency and flexibility of R&D testing.

[0110] It should be noted that the full vehicle data includes multiple types of vehicle data. The final change point detection result is obtained by fusing and deduplicating the change point detection results of each type of vehicle data. This may result in significant differences in the location of change points in feature values ​​across different types of vehicle data. To avoid a large target time window, a large amount of data in the extracted data segments, and the inclusion of a lot of useless data, this application embodiment also provides a solution, as shown below: In some possible implementations, determining a target time window based on the occurrence times of the change initiation and termination thresholds includes: in response to the change initiation and termination thresholds corresponding to the feature values ​​of each type of vehicle data satisfying preset distribution conditions, dividing the full vehicle data into at least two vehicle data groups, each including at least one type of vehicle data; for each vehicle data group, determining the target time window corresponding to that vehicle data group based on the detection results of change points in the feature values ​​of the vehicle data in that vehicle data group; subsequently, acquiring the vehicle data belonging to that vehicle data group within the target time window according to the target time window for each vehicle data group, and uploading the acquired data.

[0111] For example, the vehicle-side collects 3000 types of vehicle data, which are divided into three groups: vehicle data group 1 includes vehicle data of types 1 to 1000, vehicle data group 2 includes vehicle data of types 1001 to 2000, and vehicle data group 3 includes vehicle data of types 2001 to 3000. Vehicle data group 1 corresponds to target time window 4, vehicle data group 2 corresponds to target time window 5, and vehicle data group 3 corresponds to target time window 6. Then, vehicle data of types 1 to 1000 within target time window 4, vehicle data of types 1001 to 2000 within target time window 5, and vehicle data of types 2001 to 3000 within target time window 6 are acquired and uploaded.

[0112] The distribution condition can be a condition indicating that the location of feature value changes varies significantly across different types of vehicle data. In some embodiments, this distribution condition can be expressed as the degree of difference in the time period of feature value changes across different types of vehicle data exceeding a preset difference threshold. This degree of difference can be determined based on variance or standard deviation in statistics, and this application embodiment does not impose any limitations on this.

[0113] In some embodiments, the distribution condition can be expressed as the difference between the occurrence time of the starting critical point of the change in the feature values ​​of the full vehicle data and the occurrence time of the ending critical point of the change being greater than a preset time threshold.

[0114] The preset difference threshold and the preset time threshold can be any value, and this application embodiment does not impose any restrictions on them.

[0115] When dividing the full vehicle data into at least two vehicle data groups, grouping can be performed according to any dimension. This application does not limit this, but only provides illustrative examples of the following two implementation methods: In some possible implementations, data can be grouped according to importance to prioritize critical data highly relevant to the triggering event during subsequent data processing or uploading. This involves dividing the full vehicle data into at least two vehicle data groups based on the importance of various vehicle data types to the data upload triggering event.

[0116] In some embodiments, the importance of various vehicle data to a data upload trigger event can be determined based on a preset association mapping table. For example, the vehicle-side pre-stores association mapping tables corresponding to different types of data upload trigger events. These association mapping tables include vehicle data types associated with that type of data upload trigger event. If a certain type of vehicle data is in the association mapping table corresponding to that type of data upload trigger event, then that type of vehicle data is important; if it is not in the association mapping table corresponding to that type of data upload trigger event, then that type of vehicle data is unimportant.

[0117] In some embodiments, the importance of various vehicle data to a data upload triggering event is determined based on whether there is a correlation between the vehicle data and the data upload triggering event. For example, if the characteristic value of a certain vehicle data changes significantly within the occurrence time window of the data upload triggering event, then that vehicle data has a strong correlation with the data upload triggering event; if the characteristic value of that vehicle data remains stable within the occurrence time window of the data upload triggering event, then it is determined that it has no correlation with the data upload triggering event. Of course, other methods can also be used to determine the importance of various vehicle data, which will not be elaborated upon in this embodiment.

[0118] In some possible implementations, vehicle data can be grouped according to the distribution of characteristic values ​​over time periods. This allows multiple vehicle data sets with similar change time periods to be grouped together, effectively reducing redundant data while ensuring data integrity. Specifically, dividing the full vehicle data into at least two groups involves: based on the distribution characteristics of the start and end points of change for each type of vehicle data on the time axis, dividing the full vehicle data into at least two groups.

[0119] In some embodiments, based on the distribution characteristics of the change start critical points and change end critical points corresponding to various vehicle data on the time axis, the total vehicle data is divided into at least two vehicle data groups. This may include: clustering various vehicle data according to the change start critical points and change end critical points corresponding to various vehicle data to obtain at least two clusters, with one cluster corresponding to one vehicle data group.

[0120] In some embodiments, based on the distribution characteristics of the change start and end critical points corresponding to various vehicle data on the time axis, the full vehicle data is divided into at least two vehicle data groups, which may include: calculating the time overlap between pairs of change time periods corresponding to various vehicle data; based on the calculated time overlap, dividing the full vehicle data into at least two vehicle data groups, wherein the time overlap between pairs of change time periods corresponding to various vehicle data in any vehicle data group is greater than a preset overlap threshold.

[0121] The preset overlap threshold can be any value, and this application embodiment does not limit it. In some embodiments, the preset overlap threshold can be set by the user (such as a researcher). In some embodiments, the preset overlap threshold can be an empirical value.

[0122] The vehicle data uploading method provided in this application embodiment can upload only the original vehicle data, or it can upload the original vehicle data and then upload the feature values ​​of the vehicle data. In this way, researchers can first look at the feature values, and if the original vehicle data is determined to be valuable for analysis based on the feature values, then the original vehicle data can be analyzed, thus improving data analysis efficiency.

[0123] In some possible implementations, the method further includes uploading feature values ​​of the full vehicle data.

[0124] In some embodiments, the feature values ​​of the full vehicle data can be uploaded directly. In some embodiments, the feature values ​​of the full vehicle data can be dimensionality-reduced before uploading. That is, before uploading the feature values ​​of the full vehicle data, the method further includes: performing dimensionality reduction processing on the feature values ​​of the full vehicle data.

[0125] In some embodiments, dimensionality reduction can be achieved through a feature selection method. This feature selection method involves selecting and retaining feature values ​​from multiple types of vehicle data. In other words, the number of vehicle data types represented by the feature values ​​is reduced after dimensionality reduction.

[0126] For example, the full vehicle data includes 3000 types of vehicle data, and the feature values ​​of the full vehicle data are the feature values ​​corresponding to each of these 3000 types. After dimensionality reduction processing of the feature values ​​of the full vehicle data, feature values ​​for X types of vehicle data can be obtained. These X types are a subset of the 3000 types, and X is a value less than 3000. For example, X could be 30, 50, etc. By performing dimensionality reduction processing on the feature values ​​of the full vehicle data, only the feature values ​​of the most important types of vehicle data can be retained.

[0127] In one example, feature selection can be based on preset rules. For instance, if the feature values ​​of a certain type of vehicle data remain constant, then that type of vehicle data is meaningless and can be deleted. Conversely, if the feature values ​​of one type of vehicle data are strongly correlated with those of another type, it indicates that the two types of vehicle data represent the same vehicle state, and only the feature values ​​of one type of vehicle data can be retained.

[0128] In some embodiments, the dimensionality reduction process can also employ a feature extraction-based dimensionality reduction algorithm. It should be noted that after dimensionality reduction using this method, the resulting feature values ​​will no longer be the original feature values, but rather feature values ​​generated after mathematical transformation. In one example, a matrix-based dimensionality reduction method can be used. For instance, the feature values ​​of various vehicle data from the full vehicle dataset can be combined to construct a high-dimensional feature matrix; this high-dimensional feature matrix can then be dimensionality reduced, for example, using Principal Component Analysis (PCA), Singular Value Decomposition (SVD), or Non-negative Matrix Factorization (NMF) algorithms, to extract the core principal components from the high-dimensional feature matrix. This allows the high-dimensional feature matrix to be mapped to a low-dimensional feature matrix while retaining the main information of the original data, thus achieving data dimensionality compression.

[0129] For example, the first column of the high-dimensional feature matrix is ​​the feature value of vehicle speed, and the second column is the feature value of throttle opening. After dimensionality reduction, the feature values ​​of the first and second columns are weighted and combined to obtain the feature value of the new first column. The feature value of the new first column is neither the feature value of vehicle speed nor the feature value of throttle opening. It represents the feature value of the new concept of driving power.

[0130] In some possible implementations, the two forms of dimensionality reduction described above can be combined. For example, dimensionality reduction can be performed first using feature selection methods to reduce the number of vehicle data types. If the feature values ​​obtained after feature selection are still too dimensional (e.g., feature values ​​for the remaining 30 types of vehicle data), a feature extraction-based dimensionality reduction algorithm can be used to further reduce the dimensionality of the currently reduced feature values. This combined approach effectively balances data compression rate and data interpretability.

[0131] In some embodiments, the feature values ​​and raw vehicle data are uploaded at the same time. That is, both feature values ​​and raw vehicle data are uploaded after a data upload trigger event is detected. In some embodiments, the upload times of feature values ​​and raw vehicle data may also be different. In one example, uploading feature values ​​of the full vehicle data includes: periodically uploading feature values ​​extracted from the full vehicle data collected in the current period according to a preset upload cycle. In other words, feature values ​​are continuously uploaded, while raw vehicle data is only uploaded when a data upload trigger event is detected.

[0132] The upload period can be any duration, such as 30 seconds, 1 minute, 5 minutes, etc. This upload period can be flexibly configured according to actual business needs and network environment; this application embodiment does not impose any restrictions on it.

[0133] For example, such as Figure 2 As shown, the method for uploading vehicle data may include the following steps: S201. Collect all vehicle data and cache the collected vehicle data locally.

[0134] The vehicle-side system can establish multi-level data cache pools to continuously cache the collected raw vehicle data. Different data cache pools can be used to cache different types of vehicle data.

[0135] S202. The analysis engine detects all the vehicle data cached locally and obtains the feature values ​​of all the vehicle data cached locally. The obtained feature values ​​are then processed by dimensionality reduction and uploaded.

[0136] S203. In response to the detection of a data upload trigger event, perform change point detection on the feature values ​​of the cached full vehicle data to obtain the change point detection results.

[0137] S204. Determine the target time window based on the change point detection results.

[0138] S205. Obtain all vehicle data within the target time window and upload the obtained data.

[0139] In some possible implementations, after the feature values ​​are uploaded to the cloud, the cloud can analyze or judge the uploaded feature values ​​to determine whether the vehicle needs to upload the corresponding original vehicle data. In this way, even if the vehicle does not detect any anomalies, the cloud or R&D personnel can accurately instruct the vehicle to upload the original vehicle data for the corresponding time period when they capture hidden anomalies or long-tail trends that are difficult for the vehicle to detect, further improving R&D efficiency. Uploading the feature values ​​of the full vehicle data includes uploading the feature values ​​of the full vehicle data to the cloud. The method also includes receiving a data collection instruction from the cloud, which instructs the upload of the full vehicle data within a first time window; wherein the first time window is determined by the cloud based on the analysis of the received feature values.

[0140] For example, taking a scenario where a vehicle experiences an occasional sudden drop in battery voltage while driving as an example, the vehicle data uploading method provided in this application embodiment will be illustrated as follows: The vehicle-side caches all vehicle data collected over the past 30 minutes. When the voltage drops below a threshold (e.g., 2.5 volts), a local flag is triggered. The vehicle-side performs feature extraction on the cached full vehicle data, obtaining feature values ​​for the entire dataset. Change point detection is performed on these feature values ​​to locate the target time window. The obtained feature values ​​(several hundred bytes) along with all vehicle data within that target time window are uploaded to the cloud. Researchers reviewing the feature curves in the cloud find that the voltage drop is accompanied by no abnormal temperature. Analysis of the full vehicle data within the target time window confirms that the issue stems from a poor connection in a sampling line, rather than a cell failure.

[0141] It should be noted that the data involved in this manual (including but not limited to data used for analysis, data stored, data displayed, etc.) are all information and data authorized by the user or fully authorized by all parties. The collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation portals are provided for users to choose to authorize or refuse.

[0142] Corresponding to the above method embodiments, this application also provides an embodiment of a vehicle data uploading device.

[0143] Figure 3 This is a schematic diagram illustrating the structure of an electronic device according to an exemplary embodiment of this application. (Reference) Figure 3At the hardware level, the electronic device includes a processor 302, an internal bus 304, a network interface 306, memory 308, and non-volatile memory 310, and may also include other hardware required for business operations. The processor 302 reads the corresponding computer program from the non-volatile memory 310 into the memory 308 and then runs it. Of course, in addition to software implementation, this application does not exclude other implementation methods, such as logic devices or a combination of hardware and software, etc. That is to say, the execution subject of the following processing flow is not limited to individual logic units, but can also be hardware or logic devices.

[0144] Figure 4 This is a block diagram illustrating a vehicle data uploading device according to an exemplary embodiment of this application. (Refer to...) Figure 4 The device includes: The change point detection unit 401 is used to detect change points in the feature values ​​of the collected full vehicle data in response to the detection of a data upload trigger event, and obtain the change point detection result. The window determination unit 402 is used to determine a target time window based on the change point detection results, wherein the target time window covers the occurrence time corresponding to the detected change point; The data upload unit 403 is used to acquire all vehicle data within the target time window and upload the acquired data.

[0145] In some possible implementations, the window determination unit 402 is used to determine the change start critical point and the change end critical point based on the change point detection results; and to determine the target time window based on the occurrence time of the change start critical point and the occurrence time of the change end critical point.

[0146] In some possible implementations, the change initiation critical point is the earliest change point or the Mth stable point before the earliest change point; and / or, the change termination critical point is the latest change point or the Nth stable point after the latest change point. Wherein, M is any positive integer, and N is any positive integer.

[0147] In some possible implementations, the window determination unit 402 is used to shift the occurrence time of the change start threshold forward by a first time period to obtain the start time of the target time window; and shift the occurrence time of the change end threshold backward by a second time period to obtain the end time of the target time window.

[0148] In some possible implementations, the full vehicle data includes multiple types of vehicle data; The window determination unit 402 is used to divide the full vehicle data into at least two vehicle data groups in response to the fact that the change start threshold and change end threshold of the feature values ​​corresponding to each type of vehicle data meet the preset distribution conditions. Each vehicle data group includes at least one type of vehicle data. For each vehicle data group, the target time window corresponding to the vehicle data group is determined according to the change point detection results of the feature values ​​of the vehicle data in the vehicle data group.

[0149] In some possible implementations, the window determination unit 402 is configured to perform any of the following: Based on the importance of various vehicle data to the data upload triggering event, the full vehicle data is divided into at least two vehicle data groups; Based on the distribution characteristics of the start and end points of change corresponding to various vehicle data on the time axis, the full amount of vehicle data is divided into at least two vehicle data groups.

[0150] In some possible implementations, the data uploading unit 403 is also used to upload the feature values ​​of the full vehicle data.

[0151] like Figure 5 As shown, in some possible implementations, the device further includes: Dimensionality reduction unit 404 is used to perform dimensionality reduction processing on the feature values ​​of the full amount of vehicle data; wherein, after the dimensionality reduction processing, the number of vehicle data types to which the feature values ​​belong is reduced.

[0152] In some possible implementations, the data uploading unit 403 is used to periodically upload feature values ​​extracted from the full amount of vehicle data collected in the current period according to a preset uploading cycle.

[0153] In some possible implementations, the data uploading unit 403 is used to upload the feature values ​​of the full vehicle data to the cloud; The device further includes: The receiving unit 405 is used to receive the data collection instruction sent by the cloud, the data collection instruction being used to instruct the uploading of all vehicle data within a first time window; wherein, the first time window is determined by the cloud based on the analysis of the received feature values.

[0154] In some possible implementations, the feature value includes at least one of the following: Eigenvalues ​​of statistical characteristics; Eigenvalues ​​of time-domain features; Eigenvalues ​​of frequency domain features; The characteristic values ​​of the rate of change feature; Eigenvalues ​​of correlation features.

[0155] In some possible implementations, the preset data upload trigger event includes at least one of the following: an event of an anomaly occurring on the vehicle side, an event of entering the target scene, and receiving a data collection instruction issued by the cloud.

[0156] The specific implementation process of the functions and roles of each module in the above device can be found in the implementation process of the corresponding steps in the above method, and will not be repeated here.

[0157] The apparatus or module described in the above embodiments can be implemented by a computer chip or entity, or by a product with a certain function. A typical implementation device is a computer, which can be a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email sending and receiving device, game console, tablet computer, wearable device, or any combination of these devices.

[0158] In a typical configuration, a computer includes one or more processors, including a central processing unit (CPU) and a graphics processing unit (GPU), input / output interfaces, a network interface, and memory. The CPU is used for computational simulation, while the GPU is used to output high-quality 3D images.

[0159] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0160] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0161] Corresponding to the embodiments of the aforementioned vehicle data uploading method, this application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of any of the aforementioned vehicle data uploading methods.

[0162] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A method for uploading vehicle data, characterized in that, The method includes: In response to the detection of a data upload trigger event, change point detection is performed on the feature values ​​of the collected full vehicle data to obtain the change point detection results; Based on the change point detection results, a target time window is determined, which covers the occurrence time corresponding to the detected change point; Obtain all vehicle data within the target time window and upload the obtained data.

2. The method according to claim 1, characterized in that, The step of determining the target time window based on the change point detection results includes: Based on the change point detection results, determine the change initiation critical point and the change termination critical point; The target time window is determined based on the occurrence times of the change initiation critical point and the change termination critical point.

3. The method according to claim 2, characterized in that, The change initiation critical point is the earliest change point or the Mth stable point before the earliest change point; and / or, the change termination critical point is the latest change point or the Nth stable point after the latest change point. Wherein, M is any positive integer, and N is any positive integer.

4. The method according to claim 2, characterized in that, Determining the target time window based on the occurrence times of the change initiation critical point and the change termination critical point includes: The starting time of the target time window is obtained by shifting the occurrence time of the change initiation critical point forward by a first time duration. The termination time of the target time window is obtained by shifting the occurrence time of the change termination threshold backward by a second time period.

5. The method according to claim 2, characterized in that, The full vehicle data includes various types of vehicle data; determining the target time window based on the occurrence time of the change initiation critical point and the occurrence time of the change termination critical point includes: In response to the fact that the change start threshold and change end threshold of the feature values ​​corresponding to each type of vehicle data meet the preset distribution conditions, the full amount of vehicle data is divided into at least two vehicle data groups, and each vehicle data group includes at least one type of vehicle data. For each vehicle data group, the target time window corresponding to the vehicle data group is determined based on the detection results of the change points of the feature values ​​of the vehicle data in the vehicle data group.

6. The method according to claim 5, characterized in that, The step of dividing the full vehicle data into at least two vehicle data groups includes any one of the following: Based on the importance of various vehicle data to the data upload triggering event, the full vehicle data is divided into at least two vehicle data groups; Based on the distribution characteristics of the start and end points of change corresponding to various vehicle data on the time axis, the full amount of vehicle data is divided into at least two vehicle data groups.

7. The method according to claim 1, characterized in that, The method also includes uploading the feature values ​​of the full vehicle data.

8. The method according to claim 7, characterized in that, Before uploading the feature values ​​of the full vehicle data, the method further includes: The feature values ​​of the full vehicle data are subjected to dimensionality reduction processing.

9. The method according to claim 7, characterized in that, The feature values ​​of the uploaded full vehicle data include: According to the preset upload cycle, the feature values ​​extracted from the full amount of vehicle data collected in the current cycle are uploaded periodically.

10. The method according to claim 7, characterized in that, The step of uploading the feature values ​​of the full vehicle data includes: uploading the feature values ​​of the full vehicle data to the cloud; The method further includes: receiving a data collection instruction sent from the cloud, the data collection instruction being used to instruct the uploading of all vehicle data within a first time window; wherein, the first time window is determined by the cloud based on the analysis of received feature values.

11. The method according to any one of claims 1 to 10, characterized in that, The feature value includes at least one of the following: Eigenvalues ​​of statistical characteristics; Eigenvalues ​​of time-domain features; Eigenvalues ​​of frequency domain features; The characteristic values ​​of the rate of change feature; Eigenvalues ​​of correlation features.

12. The method according to any one of claims 1 to 10, characterized in that, The data upload triggering event includes at least one of the following: an event where an anomaly occurs on the vehicle side, an event where the vehicle enters the target scene, and an event that meets the preset triggering conditions in the data collection command issued by the cloud.

13. A vehicle data uploading device, characterized in that, The device includes: The change point detection unit is used to detect change points in the feature values ​​of the collected full vehicle data in response to the detection of a data upload trigger event, and obtain the change point detection results. A window determination unit is used to determine a target time window based on the change point detection results, wherein the target time window covers the occurrence time corresponding to the detected change point; The data upload unit is used to acquire all vehicle data within the target time window and upload the acquired data.

14. An electronic device, characterized in that, include: processor; Memory used to store processor-executable instructions; The processor implements the method as described in any one of claims 1-12 by executing the executable instructions.

15. A computer-readable storage medium storing computer instructions thereon, characterized in that, When executed by the processor, this instruction implements the steps of the method as described in any one of claims 1-12.

16. A computer program product having a computer program or instructions stored thereon, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method as described in any one of claims 1-12.