Method, device, electronic device and readable storage medium for uploading vehicle data

Abstract

The present application relates to the technical field of vehicle data management, and provides a method, device, electronic device, and readable storage medium for uploading whole vehicle data. The method includes: real-time collection of whole vehicle data and storage locally; continuous monitoring of whether fault information appears in the execution information of the actuator; when fault information appears in the execution information, the current moment is used as the fault moment, determined as the first target time period, and the whole vehicle data that has been uploaded to the cloud is removed from the whole vehicle data corresponding to the first target time period to obtain the whole vehicle data before the fault and upload it to the cloud; determined as the second target time period, and whether fault information appears in the execution information within the second target time period; if not, the whole vehicle data is uploaded to the cloud at the end of the second target time period; if so, the steps when fault information appears in the execution information are monitored are executed. The present application reduces the amount of whole vehicle data to be uploaded and the upload frequency, while ensuring the high precision and accuracy of the whole vehicle data.

Description

Technical Field

[0001] The present application relates to the technical field of vehicle data management, and in particular to a method, device, electronic device, and readable storage medium for uploading whole vehicle data. Background Art

[0002] With the development of intelligent vehicles, analyzing and uploading complete vehicle data to the cloud has become a crucial means of quickly locating vehicle-side faults. To accurately locate faults, existing data upload strategies aim to include all vehicle data. However, the continuous generation of vehicle data during operation places high demands on data transmission stability and bandwidth.

[0003] To improve transmission efficiency and reduce the need for continuous data transmission, data downscaling is currently the preferred method for collecting and uploading large data. This involves collecting vehicle data at a lower accuracy level before uploading it to the cloud. While this method reduces the frequency of collection and upload, the reduced accuracy makes it unlikely that the uploaded data volume will support fault analysis if high-precision data is required.

[0004] Therefore, how to provide a solution to the above technical problems is a problem that those skilled in the art need to solve. Summary of the Invention

[0005] In view of this, the embodiments of the present application provide a method, device, electronic device and readable storage medium for uploading whole vehicle data to solve the problem in the prior art that whole vehicle data cannot support fault analysis.

[0006] A first aspect of an embodiment of the present application provides a method for uploading vehicle data, comprising:

[0007] Collect vehicle data in real time and store it locally;

[0008] Continuously monitor the actuator's execution information for fault information;

[0009] When fault information is detected in the execution information, the current time is used as the fault time, and a time period with the fault time as the end point and a first preset time length is determined as a first target time period. The vehicle data uploaded to the cloud is removed from the vehicle data corresponding to the first target time period to obtain the vehicle data before the fault, and the vehicle data before the fault is uploaded from the local computer to the cloud.

[0010] Determine a time period starting from the fault moment and having a second preset time length as a second target time period, and monitor whether fault information appears in the execution information within the second target time period;

[0011] If not, at the end of the second target time period, the vehicle data corresponding to the second target time period is uploaded from the local computer to the cloud;

[0012] If yes, execute the steps for when fault information is detected in the execution information.

[0013] A second aspect of an embodiment of the present application provides a device for uploading vehicle data, comprising:

[0014] The acquisition module is used to collect vehicle data in real time and store it locally;

[0015] A monitoring module is used to continuously monitor whether there is any fault information in the execution information of the actuator;

[0016] an uploading module configured to, when the monitoring module detects fault information in the execution information, use the current time as the fault time, determine a time period with the fault time as the end point and a first preset time period as the first target time period, remove the vehicle data uploaded to the cloud from the vehicle data corresponding to the first target time period to obtain the vehicle data before the fault, and upload the vehicle data before the fault from the local computer to the cloud;

[0017] The above-mentioned monitoring module is also used to determine a time period with the fault moment as the starting point and a second preset time period as the second target time period, and monitor whether fault information appears in the execution information within the second target time period; if not, the upload module is triggered to upload the whole vehicle data corresponding to the second target time period from the local to the cloud at the end time of the second target time period; if so, the upload module is triggered to execute the steps when fault information is detected in the execution information.

[0018] According to a third aspect of an embodiment of the present application, an electronic device is provided, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of the above method when executing the computer program.

[0019] According to a fourth aspect of an embodiment of the present application, a readable storage medium is provided, which stores a computer program. When the computer program is executed by a processor, the steps of the above method are implemented.

[0020] The beneficial effects of the embodiments of the present application compared with the prior art include at least the following: the embodiments of the present application use the monitoring of fault information as a trigger condition for uploading the whole vehicle data, and once the fault information is detected, the whole vehicle data before and after the fault moment is uploaded. The embodiments of the present application reduce the amount of whole vehicle data to be uploaded and the frequency of uploading by determining the range of the whole vehicle data and setting the time of the upload action, and on the other hand, ensure the high precision and accuracy of the whole vehicle data, providing effective support for fault analysis. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for use in the embodiments or descriptions of the prior art. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0022] Figure 1 This is a schematic diagram of an application scenario of an embodiment of the present application;

[0023] Figure 2 This is a flow chart of a method for uploading vehicle data provided in an embodiment of the present application;

[0024] Figure 3 This is a data diagram of a single fault information provided by an embodiment of the present application;

[0025] Figure 4 This is a data diagram of multiple fault information provided by an embodiment of the present application;

[0026] Figure 5 This is another data diagram of multiple fault information provided by an embodiment of the present application;

[0027] Figure 6 This is another data diagram of multiple fault information provided by an embodiment of the present application;

[0028] Figure 7 This is a schematic diagram of the structure of a vehicle data uploading device provided in an embodiment of the present application;

[0029] Figure 8 This is a structural diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0030] In the following description, specific details such as specific system structures and techniques are provided for purposes of illustration rather than limitation to facilitate a thorough understanding of the embodiments of the present application. However, it will be apparent to those skilled in the art that the present application may be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well-known systems, devices, circuits, and methods are omitted to avoid obscuring the description of the present application with unnecessary detail.

[0031] The following will describe in detail a method, device, electronic device and readable storage medium for uploading vehicle data according to an embodiment of the present application with reference to the accompanying drawings.

[0032] Figure 1Schematic diagram of the application scenario of the embodiment of the present application. The application scenario may include a vehicle system 101 and a cloud platform 102, wherein the vehicle system 101 includes at least a plurality of actuator ECUs, a vehicle controller, and a TBOX (TelematicsBox, an on-board communication terminal), wherein each actuator ECU transmits execution information to the vehicle controller via the CAN bus, and the vehicle controller can also collect vehicle data via the CAN bus. The vehicle controller is connected to the TBOX, and the TBOX is used to communicate with the cloud platform 102. The cloud platform 102 refers to the TSP (Telematics Service Provider, an on-board terminal service platform), which is one of the important components of the Internet of Vehicles system. TSP is a platform that provides services such as remote monitoring, control, navigation, and entertainment of vehicles, and realizes data interaction with the vehicle system by communicating with the TBOX.

[0033] It should be noted that the specific internal structure of the vehicle system 101 and the specific type of the cloud platform 102 can be adjusted according to the actual needs of the application scenario, and the embodiments of the present application do not limit this.

[0034] Figure 2 This is a flow chart of a method for uploading vehicle data provided in an embodiment of the present application. Figure 2 The upload method can be Figure 1 The vehicle controller in the vehicle system is executed. Figure 2 As shown, the upload method includes:

[0035] S201: Collect vehicle data in real time and store it locally, and continuously monitor whether there is any fault information in the actuator's execution information;

[0036] S202: When fault information is detected in the execution information, the current time is used as the fault time, a time period with the fault time as the end point and a first preset time period as the first target time period, the vehicle data uploaded to the cloud is removed from the vehicle data corresponding to the first target time period to obtain the vehicle data before the fault, and the vehicle data before the fault is uploaded from the local computer to the cloud;

[0037] S203: Determine a time period starting from the fault moment and lasting for a second preset time period as a second target time period, and monitor whether fault information appears in the execution information within the second target time period; if so, return to step S202; otherwise, execute step S204;

[0038] S204: Uploading the vehicle data corresponding to the second target time period from the local computer to the cloud at the end of the second target time period.

[0039] Among them, the action of collecting vehicle data and storing it locally, and the action of monitoring whether fault information occurs, are two parallel threads that do not interfere with each other, and have no connection or sequence.

[0040] When fault information is detected, the entire vehicle data is uploaded. When the cloud analyzes the fault information, the required entire vehicle data includes the entire vehicle data corresponding to the first target time period before the fault moment and the entire vehicle data corresponding to the second target time period after the fault moment. However, considering that the data to be uploaded for different fault information is the entire vehicle data, if multiple fault information occurs consecutively and their first and second target time periods overlap, only one upload of the entire vehicle data is required. Therefore, to avoid repeated uploads of the entire vehicle data, this embodiment sets more specific time period divisions for uploading data and the timing of the upload action in steps S202-S204.

[0041] For each fault information, in addition to the required range of vehicle data must be comprehensive without omission, it is also required that the upload timing must be timely. Therefore, in the embodiment of the present application, two necessary vehicle data upload times are set, one is the fault time when the fault information is detected, and the other is the post-fault upload time after waiting for the second preset time after the fault information, that is, the end time of the second target time period. If new fault information appears before waiting for the post-fault upload time, the vehicle data is directly uploaded at the new fault time, that is, step S202 is executed, and step S204 regarding the post-fault upload time is discarded. That is to say, the priority of the post-fault upload time is lower than the fault time.

[0042] like Figure 3 As shown, when the first fault information appears in the monitoring execution information, the current time when the fault information appears is determined as the fault time T1, and the time period (T1-△t1, T1) with the fault time T1 as the end point and a first preset time length △t1 as the duration is determined as the first target time period. Since there is no other vehicle data uploaded to the cloud before the fault information, the vehicle data corresponding to the first target time period (T1-△t1, T1) before the fault time T1 is directly uploaded to the cloud as the vehicle data before the fault. This upload action is executed immediately after the fault information is detected. Then, the execution information is continuously monitored, and the time period (T1, T1+△t2) with the fault time T1 as the start point and a second preset time length △t2 as the second target time period. If there is no new fault information within the second target time period (T1, T1+△t2) after the fault time T1, the vehicle data corresponding to the second target time period (T1, T1+△t2) is uploaded at the end point T1+△t2 of the second target time period. This upload action is executed at the end point of the second target time period.

[0043] There are three situations in which the vehicle data to be uploaded of two adjacent fault information overlap. One is that the vehicle data to be uploaded of the two fault information do not overlap at all, such as Figure 4 The second type is that the time periods for uploading the vehicle data of the two fault information only overlap the second target time period of the previous fault information, as shown in Figure 5 The third type is that the time periods for uploading the vehicle data of two fault information overlap with the first target time period and the second target time period of the previous fault information, as shown in Figure 6 In fact, the latter two methods are both the execution effects of returning to step S202 when the judgment result of step S203 is yes.

[0044] Assume that a second fault message is detected in the execution information, and the current time of the fault message is taken as the fault time T2, corresponding to the first target time period (T2-△t1, T2) and the second target time period (T2, T2+△t2). Since there is fault information before the fault message appears, it is necessary to determine whether the vehicle data corresponding to the first target time period corresponding to the fault time T2 includes the vehicle data uploaded to the cloud. The specific judgment method is to determine the size of T2-T1 and △t1+△t2. If T2-T1≥△t1+△t2, that is, there is no data time period overlap, then the vehicle data corresponding to the first target time period does not include the vehicle data uploaded to the cloud, such as Figure 4 As shown, the first fault information uploads the vehicle data of the first target time period at the fault time T1, and uploads the vehicle data of the second target time period at the end time T1+Δt2 of the second target time period.

[0045] If T2-T1<△t1+△t2, then the vehicle data corresponding to the first target time period (T2-△t1, T2) includes the vehicle data that has been uploaded to the cloud, and the vehicle data that has been uploaded to the cloud needs to be deleted. The remaining vehicle data before the fault to be uploaded is the vehicle data corresponding to the time period from the last upload time to the current fault time T2. The last upload time may be the end time of the second target time period of the last fault information, T1+△t2. Figure 5 As shown, the time period corresponding to the vehicle data before the fault is (T1+△t2, T2); the last upload time may also be the fault time T1 of the previous fault information, such as Figure 6 As shown, the time period corresponding to the vehicle data before the fault is (T1, T2). As for the last upload time, there is no need to calculate it. The corresponding upload time can be recorded each time the data is uploaded and used in the subsequent process.

[0046] The specific time values of the first preset time length and the second preset time length can be set according to actual conditions or working conditions. For example, both can be set to 10s or other time values.

[0047] It should be noted that the time period markings in the above text are only used to describe the starting and ending times of the time period. For example, (T1, T2) refers to the time period with the starting time T1 and the ending time T2. The parentheses do not refer to the open interval.

[0048] In the embodiment of the present application, the monitoring of fault information is used as a trigger condition for uploading the whole vehicle data. Once the fault information is detected, the whole vehicle data before and after the fault is uploaded. In the embodiment of the present application, by determining the range of the whole vehicle data and setting the time of the upload action, on the one hand, the amount of whole vehicle data to be uploaded and the frequency of uploading are reduced; on the other hand, the high precision and accuracy of the whole vehicle data are ensured, thereby providing effective support for fault analysis.

[0049] In some specific embodiments, the process of continuously monitoring whether fault information appears in the execution information of the actuator includes:

[0050] Continuously monitor the execution information of the actuator, and when abnormal information appears in the execution information and the abnormal information meets the fault judgment condition, determine that fault information appears in the execution information.

[0051] It's understood that not all exceptions in the execution information are considered faults. They are considered faults only when they meet the fault determination criteria. These fault determination criteria can be configured via configuration instructions issued from the cloud. Specifically, the fault determination criteria include: the exception information being the exception information specified in the configuration instructions issued from the cloud.

[0052] Furthermore, for abnormal information that occurs frequently, or situations where the frequency or number of occurrences of abnormal information requires special attention, different fault judgment conditions can be set accordingly, that is, the fault judgment conditions include: the abnormal information is abnormal information that is the same as the previous abnormal information and the occurrence interval meets the periodic judgment condition.

[0053] For example, the continuous occurrence of abnormal information A may be a continuous error report of the same fault phenomenon. In order to avoid data interference, the period determination condition of abnormal information A can be set to be greater than 10s. Only when the interval between the current abnormal information A and the previous abnormal information A is greater than 10s, the current abnormal information A is considered to be fault information. For another example, abnormal information B, which does not normally appear continuously, can be set to a period determination condition of less than 5s to increase the sensitivity to abnormal information B. If the interval between the current abnormal information B and the previous abnormal information B is less than 5s, the current abnormal information B is considered to be fault information. The period determination condition obtained from the above can include: the occurrence interval is outside the normal occurrence frequency range corresponding to the abnormal information. The normal occurrence frequency range corresponding to abnormal information A is 0 to 10s, and the normal occurrence frequency range corresponding to abnormal information B is greater than 5s. In addition to the above examples, the period determination condition can also be adjusted according to actual needs and working conditions, which will not be repeated here.

[0054] Furthermore, some fault information only requires uploading the entire vehicle data once. In order to reduce the frequent data uploading caused by multiple occurrences of the same abnormal information, the periodic judgment conditions can also be set to include: the abnormal information is the first abnormal information to appear in the current ignition cycle.

[0055] Considering that the fault information of the entire vehicle system that needs to be uploaded in the vehicle system should be the key faults that need attention, the fault information includes one or more of thermal management fault information, collision fault information, and brake fault information. The fault information here can correspond to a large category, and each large category includes abnormal faults of multiple single sensors or parameters. For example, thermal management fault information may include the sensor temperature of multiple single cells. Regardless of the specific form of the abnormal information, the fault information determined at the time of final upload is the fault of the large category corresponding to the abnormal information. For example, regardless of which sensor temperature is abnormal, the determined fault information is uniformly classified as thermal management fault information. In addition to the several fault information exemplified above, this embodiment may also include other fault information that requires attention, which is not limited here.

[0056] All of the above optional technical solutions can be combined in any way to form optional embodiments of the present application, and will not be described in detail here. It should be understood that the order of the sequence numbers of the steps in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0057] The following are device embodiments of the present application, which can be used to implement the method embodiments of the present application. For details not disclosed in the device embodiments of the present application, please refer to the method embodiments of the present application.

[0058] Figure 7This is a schematic diagram of a vehicle data uploading device provided in an embodiment of the present application. Figure 4 As shown, the uploading device includes:

[0059] The acquisition module 701 is used to collect vehicle data in real time and store it locally;

[0060] Monitoring module 702, used to continuously monitor whether fault information appears in the execution information of the actuator;

[0061] The uploading module 703 is configured to, when the monitoring module detects fault information in the execution information, use the current time as the fault time, determine a time period with the fault time as the end point and a first preset time period as the first target time period, remove the vehicle data uploaded to the cloud from the vehicle data corresponding to the first target time period to obtain the vehicle data before the fault, and upload the vehicle data before the fault from the local computer to the cloud;

[0062] The monitoring module 702 is also used to determine a time period with the fault moment as the starting point and a second preset time period as the second target time period, and monitor whether fault information appears in the execution information within the second target time period; if not, the upload module 703 is triggered to upload the entire vehicle data corresponding to the second target time period from the local to the cloud at the end moment of the second target time period; if so, the upload module 703 is triggered to execute the steps when fault information is detected in the execution information.

[0063] Among them, the action of collecting vehicle data and storing it locally, and the action of monitoring whether fault information occurs, are two parallel threads that do not interfere with each other, and have no connection or sequence.

[0064] When fault information is detected, the entire vehicle data is uploaded. When the cloud analyzes the fault information, the required entire vehicle data includes the entire vehicle data corresponding to the first target time period before the fault moment and the entire vehicle data corresponding to the second target time period after the fault moment. However, considering that the data to be uploaded for different fault information is the entire vehicle data, if multiple fault information occurs consecutively and their first and second target time periods overlap, only one upload of the entire vehicle data is required. Therefore, to avoid repeated uploads of the entire vehicle data, this embodiment sets more specific time period divisions for uploading data and the timing of the upload action in the monitoring module 702 and the uploading module 703 to avoid repeated uploads of the entire vehicle data.

[0065] For each fault information, in addition to the required range of vehicle data must be comprehensive without omission, it is also required that the upload timing must be timely. Therefore, in the embodiment of the present application, two necessary vehicle data upload times are set, one is the fault time when the fault information is detected, and the other is the post-fault upload time after waiting for the second preset time after the fault information, that is, the end time of the second target time period. If new fault information appears before waiting for the post-fault upload time, the vehicle data will be uploaded directly at the new fault time, that is, the detection upload module 703 will be triggered to upload the vehicle data before the fault, and the content about the post-fault upload time will be discarded. That is to say, the priority of the post-fault upload time is lower than the fault time.

[0066] In the embodiment of the present application, the monitoring of fault information is used as a trigger condition for uploading the whole vehicle data. Once the fault information is detected, the whole vehicle data before and after the fault is uploaded. In the embodiment of the present application, by determining the range of the whole vehicle data and setting the time of the upload action, on the one hand, the amount of whole vehicle data to be uploaded and the frequency of uploading are reduced; on the other hand, the high precision and accuracy of the whole vehicle data are ensured, thereby providing effective support for fault analysis.

[0067] In some specific embodiments, the process of continuously monitoring whether fault information appears in the execution information of the actuator includes: continuously monitoring the execution information of the actuator, and when abnormal information appears in the execution information and the abnormal information meets the fault judgment condition, determining that fault information appears in the execution information.

[0068] In some specific embodiments, the fault determination condition includes: the exception information corresponds to the exception information in the configuration instructions issued by the cloud. It should be understood that the presence of exception information in the execution information does not necessarily constitute fault information; only when the exception information meets the fault determination condition can it be considered fault information. Here, the fault determination condition can be set via the configuration instructions issued by the cloud, that is, the fault determination condition includes: the exception information corresponds to the exception information in the configuration instructions issued by the cloud.

[0069] In some specific embodiments, the fault determination condition includes: the abnormal information is the same as the previous abnormal information, and the interval between occurrences satisfies a period determination condition. For example, the continuous occurrence of abnormal information A may be a series of errors caused by the same fault phenomenon. To avoid data interference, the period determination condition for abnormal information A can be set to greater than 10 seconds. Only when the interval between the current abnormal information A and the previous abnormal information A is greater than 10 seconds is the current abnormal information A considered a fault. For another example, abnormal information B, which normally does not occur continuously, can be set to a period determination condition of less than 5 seconds to increase sensitivity to abnormal information B. If the interval between the current abnormal information B and the previous abnormal information B is less than 5 seconds, the current abnormal information B is considered a fault. Based on the above, the period determination condition can also include: the interval between occurrences is outside the normal occurrence frequency range corresponding to the abnormal information. The normal occurrence frequency range for abnormal information A is 0 to 10 seconds, and the normal occurrence frequency range for abnormal information B is greater than 5 seconds. In addition to the above examples, the period determination condition can be adjusted according to actual needs and operating conditions, and will not be further explained here.

[0070] In some specific embodiments, the cycle determination condition includes: the abnormal information is the first abnormal information to appear in the current ignition cycle.

[0071] In some specific embodiments, the period determination condition includes: the occurrence interval is outside the regular occurrence frequency range corresponding to the abnormal information.

[0072] In some specific embodiments, fault information includes one or more of thermal management fault information, collision fault information, and braking fault information. Fault information here can correspond to a broad category, with each broad category encompassing abnormal faults of multiple individual sensors or parameters. For example, thermal management fault information can include the sensor temperatures of multiple single-cell batteries. Regardless of the specific manifestation of the abnormal information, the fault information ultimately determined upon upload is the fault of the broad category corresponding to the abnormal information. For example, regardless of which sensor temperature is abnormal, the determined fault information is uniformly categorized as thermal management fault information. In addition to the fault information exemplified above, this embodiment may also include other fault information requiring attention, which is not limited here.

[0073] Figure 8 Schematic diagram of the electronic device 8 provided in the embodiment of the present application. Figure 8 As shown, the electronic device 8 of this embodiment includes: a processor 801, a memory 802, and a computer program 803 stored in the memory 802 and executable by the processor 801. When the processor 801 executes the computer program 803, the steps of the above-described method embodiments are implemented. Alternatively, when the processor 801 executes the computer program 803, the functions of the modules / units in the above-described device embodiments are implemented.

[0074] The electronic device 8 may be a desktop computer, a notebook, a PDA, a cloud server, or other electronic device. The electronic device 8 may include but is not limited to a processor 801 and a memory 802. Those skilled in the art will appreciate that Figure 8 This is merely an example of the electronic device 8 and does not limit the electronic device 8 . The electronic device 8 may include more or fewer components than shown in the figure, or different components.

[0075] The processor 801 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0076] The memory 802 can be an internal storage unit of the electronic device 8, such as a hard disk or memory of the electronic device 8. The memory 802 can also be an external storage device of the electronic device 8, such as a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash memory card, etc. equipped on the electronic device 8. The memory 802 can also include both an internal storage unit of the electronic device 8 and an external storage device. The memory 802 is used to store computer programs and other programs and data required by the electronic device.

[0077] Those skilled in the art will clearly understand that for the sake of convenience and brevity of description, only the division of the above-mentioned functional units and modules is used as an example for illustration. In actual applications, the above-mentioned functions can be distributed and completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The above-mentioned integrated units can be implemented in the form of hardware or in the form of software functional units.

[0078] If the integrated module / unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the present application implements all or part of the process in the above-mentioned embodiment method, and can also be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a readable storage medium, and when the computer program is executed by the processor, it can implement the steps of the above-mentioned various method embodiments. The computer program may include computer program code, which may be in source code form, object code form, executable file or some intermediate form. The readable storage medium may include: any entity or device capable of carrying computer program code, recording medium, USB flash drive, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electric carrier signal, telecommunication signal and software distribution medium. It should be noted that the content contained in the readable storage medium can be appropriately increased or decreased according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, the readable storage medium does not include electric carrier signal and telecommunication signal.

[0079] The above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the various embodiments of the present application, and should all be included in the scope of protection of the present application.

Claims

1. A method for uploading vehicle data, characterized in that: include: Collect vehicle data in real time and store it locally; Continuously monitor the actuator's execution information for fault information; When the fault information is detected in the execution information, the current time is used as the fault time, a time period with the fault time as the end point and a first preset time period is determined as a first target time period, the vehicle data uploaded to the cloud is removed from the vehicle data corresponding to the first target time period to obtain the vehicle data before the fault, and the vehicle data before the fault is uploaded from the local computer to the cloud; Determine a time period starting from the fault moment and having a second preset time length as a second target time period, and monitor whether fault information appears in the execution information within the second target time period; If not, uploading the vehicle data corresponding to the second target time period from the local device to the cloud at the end time of the second target time period; If so, execute the step of detecting the fault information in the execution information.

2. The method according to claim 1, characterized in that The process of continuously monitoring the actuator's execution information for fault information includes: Continuously monitor execution information of the actuator, and when abnormal information appears in the execution information and the abnormal information meets a fault determination condition, determine that fault information appears in the execution information.

3. The method according to claim 2, characterized in that The fault judgment conditions include: The abnormal information is the abnormal information corresponding to the configuration instruction issued by the cloud.

4. The method according to claim 2, characterized in that The fault judgment conditions include: The abnormality information is abnormality information in which the occurrence interval of the abnormality information that is the same as the previous one satisfies a period determination condition.

5. The method according to claim 4, characterized in that The period determination conditions include: The abnormal information is the abnormal information that occurs for the first time in the current ignition cycle.

6. The method according to claim 4, characterized in that The period determination conditions include: The occurrence interval is outside the normal occurrence frequency range corresponding to the abnormal information.

7. The method according to any one of claims 1 to 6, characterized in that The fault information includes one or more of thermal management fault information, collision fault information, and braking fault information.

8. A device for uploading vehicle data, characterized in that: include: The acquisition module is used to collect vehicle data in real time and store it locally; A monitoring module is used to continuously monitor whether there is any fault information in the execution information of the actuator; an uploading module, configured to, when the monitoring module detects the occurrence of the fault information in the execution information, use the current time as the fault time, determine a time period with the fault time as the end point and a first preset time period as a first target time period, remove the vehicle data uploaded to the cloud from the vehicle data corresponding to the first target time period to obtain vehicle data before the fault, and upload the vehicle data before the fault from the local computer to the cloud; The monitoring module is further configured to determine a time period starting from the fault moment and having a second preset duration as a second target time period, and monitor whether fault information appears in the execution information within the second target time period; if not, trigger the upload module to upload the entire vehicle data corresponding to the second target time period from the local to the cloud at the end moment of the second target time period; if so, trigger the upload module to execute the steps when the fault information is detected in the execution information.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 7 are implemented.

10. A readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 7 are implemented.

Images