OTA update method, vehicle, storage medium, and product

Abstract

Disclosed are an OTA update method, a vehicle, a storage medium, and a product. The method comprises: receiving an OTA update task, and then acquiring a current vehicle state of a vehicle; when the current vehicle state meets a preset vehicle condition, performing a pre-update verification on the vehicle, wherein the preset vehicle condition comprises a changed condition obtained by changing a verification condition in a preset original pre-verification, and the pre-update verification is obtained by removing from the preset original pre-verification a verification condition corresponding to the changed condition; and after the vehicle passes the pre-update verification, executing the OTA update task.

Description

OTA update methods, vehicles, storage media and products

[0001] Related applications

[0002] This application claims priority to Chinese patent applications filed on October 29, 2024, with application number 202411525273.8, 202411523220.2, 202411523220.2, and 202411525452.1, the entire contents of which are incorporated herein by reference. Technical Field

[0003] This application relates to the field of OTA (Over-the-Air Technology) technology, and more particularly to an OTA update method, vehicle, storage medium, and product. Background Technology

[0004] OTA (Over-the-Air Technology) refers to remotely updating system software via the internet. As OTA technology becomes increasingly prevalent in new energy vehicles, OEMs are striving to optimize OTA performance and reduce its time consumption. In related vehicle OTA upgrade technologies, a pre-verification process is typically performed to ensure successful upgrades. This pre-verification process also takes time, and the vehicle will enter BOOT mode during this time (in which the user cannot use the vehicle). Users will consider the time spent on pre-verification as part of the OTA upgrade cycle. Therefore, in practical applications, the aforementioned vehicle OTA upgrade technologies tend to have longer upgrade times, thus impacting the user's vehicle experience.

[0005] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0006] The main purpose of this application is to provide an OTA update method, vehicle, storage medium and product, which aims to solve the technical problem of long upgrade time in the practical application of related vehicle OTA upgrade technology.

[0007] To achieve the above objectives, this application proposes an OTA update method, which includes the following steps:

[0008] After receiving an OTA update task, obtain the vehicle's current vehicle status;

[0009] When the current vehicle status meets the preset vehicle conditions, the vehicle is subjected to a pre-update verification. The preset vehicle conditions include modified conditions obtained by changing the verification conditions in the preset original pre-update verification. The pre-update verification is obtained by removing the verification conditions corresponding to the modified conditions in the preset original pre-update verification.

[0010] After the pre-update verification passes, the OTA update task is executed.

[0011] In one embodiment, after the step of obtaining the current vehicle status, the method further includes:

[0012] If the current vehicle status does not meet the preset vehicle conditions, a prompt message is determined based on the target status information in the current vehicle status that does not meet the preset vehicle conditions.

[0013] The prompt message is displayed on the vehicle's infotainment screen.

[0014] In one embodiment, the step of performing pre-update verification on the vehicle includes:

[0015] Obtain the vehicle information of the vehicle;

[0016] If the vehicle information meets the verification conditions of the pre-update verification, the pre-update verification is determined to be passed. The verification conditions of the pre-update verification include at least one of the following: the vehicle has obtained update authorization; the vehicle's identity identifier is the same as the task vehicle identifier of the OTA update task; there are no occupants in the vehicle; the vehicle's power supply is active; the vehicle's three-electric system is in OTA state; the vehicle's anti-theft system is normal; the vehicle is in full vehicle lockout; each update unit in the vehicle corresponding to the OTA update task is online; the preset update unit in each update unit has received the update file key; the vehicle's management module is in OTA state; and the vehicle's fault codes have been cleared. Each update unit is an electronic control unit that controls the vehicle.

[0017] In one embodiment, the step of performing the OTA update task includes:

[0018] For any one of the update units corresponding to the OTA update task, determine the target update data corresponding to the update unit;

[0019] The target update data is written to the data storage area of ​​the update unit, and the data stored in the data storage area is verified after the writing is completed;

[0020] After the verification is passed, the update unit is updated.

[0021] In one embodiment, after the step of determining the target update data corresponding to the update unit, the method includes:

[0022] If the target update data fails to be written to the data storage area, or if the data stored in the data storage area fails to be verified, then the historical data in the data backup area corresponding to the update unit is used to overwrite the data stored in the data storage area, so as to roll back the system version of the update unit.

[0023] In one embodiment, prior to the step of writing the target update data to the data storage area of ​​the update unit, the method includes:

[0024] The collaborative units associated with the update unit are determined based on a preset collaborative work unit mapping table;

[0025] The unit functions of the update unit and the coordination unit are disabled, wherein the unit functions of the update unit are re-enabled after the update unit finishes updating and the coordination unit that needs to be updated finishes updating.

[0026] Furthermore, to achieve the above objectives, this application also proposes an OTA update device, the OTA update device comprising:

[0027] The acquisition module is used to obtain the current vehicle status after receiving an OTA update task;

[0028] The verification module is used to perform a pre-update verification on the vehicle when the current vehicle status meets the preset vehicle conditions. The preset vehicle conditions include modified conditions obtained by changing the verification conditions in the preset original pre-update verification. The pre-update verification is obtained by removing the verification conditions corresponding to the modified conditions in the preset original pre-update verification.

[0029] An execution module is used to execute the OTA update task after the pre-update verification passes.

[0030] To achieve the above objectives, this application also proposes an OTA update method, which includes the following steps:

[0031] Receive OTA update task and determine the execution time for the vehicle to complete the OTA update task;

[0032] If the execution time is less than or equal to the verification time required to perform the preset vehicle update pre-verification, the preset vehicle update pre-verification is skipped.

[0033] Execute the OTA update task.

[0034] In one embodiment, after the step of receiving the OTA update task, the method includes:

[0035] Obtain the current vehicle status;

[0036] If the current vehicle status meets the preset vehicle conditions, the step of determining the execution time for the vehicle to complete the OTA update task is executed.

[0037] If the current vehicle status does not meet the preset vehicle conditions, a prompt message is output based on the target status information in the current vehicle status that does not meet the preset vehicle conditions.

[0038] In one embodiment, after the step of receiving the OTA update task, the method further includes:

[0039] If the execution time is longer than the vehicle pre-verification time, the preset vehicle pre-update verification is performed.

[0040] After the preset vehicle update pre-verification is passed, the OTA update task is executed.

[0041] In one embodiment, the step of performing the preset vehicle pre-update verification includes:

[0042] Obtain the vehicle information of the vehicle;

[0043] If the vehicle information meets the preset vehicle pre-update verification items, the preset vehicle pre-update verification is determined to be passed. The preset vehicle pre-update verification items include at least one of the following: the vehicle has obtained update authorization; the vehicle's identity identifier is the same as the task vehicle identifier of the OTA update task; there are no occupants in the vehicle; the vehicle's power supply is active; the vehicle's three-electric system has entered OTA status; the vehicle's anti-theft system is normal; the vehicle is locked; each update unit in the vehicle corresponding to the OTA update task is online; the preset update unit in each update unit has received the update file key; the vehicle's management module has entered OTA status; and the vehicle's fault codes have been cleared.

[0044] In one embodiment, the step of determining the execution time for the vehicle to complete the OTA update task includes:

[0045] Determine the local update duration required for each update unit in the vehicle corresponding to the OTA update task;

[0046] The execution time for the vehicle to complete the OTA update task is determined based on the duration of each local update.

[0047] In one embodiment, the step of determining the execution time for the vehicle to complete the OTA update task based on the duration of each local update includes:

[0048] Based on the current vehicle usage scenario, the ignore update units in each update unit are determined, wherein the ignore update units are update units whose usage probability is less than a preset threshold in the current usage scenario;

[0049] The local update durations of the ignored update units are removed from each of the local update durations to obtain the target local update duration set;

[0050] Based on the longest local update duration in the target local update duration set, the execution time for the vehicle to complete the OTA update task is determined.

[0051] Furthermore, to achieve the above objectives, this application also proposes an OTA update device, the OTA update device comprising:

[0052] The determination module is used to receive OTA update tasks and determine the execution time for the vehicle to complete the OTA update task;

[0053] The skip module is used to skip the preset vehicle update pre-verification if the execution time is less than or equal to the verification time required to perform the preset vehicle update pre-verification.

[0054] The execution module is used to execute the OTA update task.

[0055] To achieve the above objectives, this application proposes an OTA update method, which includes the following steps:

[0056] Receive OTA update tasks and determine the vehicle's idle upgrade period for the OTA update task;

[0057] If the vehicle is in an idle upgrade period, skip the vehicle's pre-update verification and execute the OTA update task.

[0058] In one embodiment, the step of determining the vehicle's idle upgrade period for the OTA update task includes:

[0059] When the vehicle is in the custom appointment upgrade mode, the custom upgrade time slot is received and the custom upgrade time slot is used as the vehicle's idle upgrade time slot.

[0060] In one embodiment, the step of determining the vehicle's idle upgrade period for the OTA update task further includes:

[0061] When the vehicle is in the recommended upgrade mode, predict the vehicle's future idle time periods to obtain candidate time periods, and output the candidate time periods;

[0062] The selected candidate time period will be used as the vehicle idle upgrade time period.

[0063] In one embodiment, the step of predicting future idle time periods of the vehicle to obtain candidate time periods includes:

[0064] Obtain time-period characteristic data for a preset future time period;

[0065] The time period feature data is input into a preset idle prediction model to obtain the vehicle's future idle time periods;

[0066] Candidate time periods are obtained from the idle time periods based on the upgrade duration of the OTA update task.

[0067] In one embodiment, before the step of inputting the time period feature data into a preset idle prediction model to obtain the vehicle's future idle time periods, the method includes:

[0068] Generate a target training sample set corresponding to the vehicle based on the vehicle's historical usage records;

[0069] The initial pre-trained prediction model is fine-tuned based on the training samples in the target training sample set to obtain the preset idle prediction model.

[0070] In one embodiment, the step of generating a target training sample set corresponding to the vehicle based on the vehicle's historical usage records includes:

[0071] Based on the historical vehicle usage records, each sample time period is divided, wherein each sample time period includes the vehicle's historical usage time period and the vehicle's historical non-use time period;

[0072] For any one of the sample time periods, obtain the sample feature data of the sample time period, wherein the sample feature data includes at least one of the following: the time period interval of the sample time period, the weather conditions of the sample time period, the vehicle usage cost information corresponding to the sample time period, and the social event information of the sample time period.

[0073] Training samples are generated by labeling the sample feature data with the sample time period, wherein when the sample time period is a historical vehicle usage time period, the label of the sample feature data is the vehicle usage time period, and when the sample time period is a historical non-vehicle usage time period, the label of the sample feature data is the idle time period.

[0074] The target training sample set is constructed by using training samples generated based on each sample time period.

[0075] In one embodiment, the OTA update method further includes:

[0076] When the vehicle is in an idle upgrade period, obtain the current vehicle status;

[0077] If the current vehicle status meets the preset vehicle conditions, then the step of skipping the pre-update verification of the vehicle is executed;

[0078] If the current vehicle status does not meet the preset vehicle conditions, then the abnormal vehicle status that does not meet the preset vehicle conditions in the current vehicle status is output.

[0079] Furthermore, to achieve the above objectives, this application also proposes an OTA update device, the OTA update device comprising:

[0080] The determination module is used to receive OTA update tasks and determine the vehicle's idle upgrade period for the OTA update task;

[0081] The skip module is used to skip the vehicle's pre-update verification and execute the OTA update task when the vehicle is in an idle upgrade period.

[0082] In addition, to achieve the above objectives, this application also proposes a vehicle comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the OTA update method as described above.

[0083] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and which, when executed by a processor, implements the steps of the OTA update method as described above.

[0084] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the OTA update method described above.

[0085] One or more technical solutions proposed in this application have at least the following technical effects:

[0086] In this embodiment, upon receiving an OTA update task, the current vehicle status is obtained. If the current vehicle status meets preset vehicle conditions, a pre-update verification is performed on the vehicle. The preset vehicle conditions include modified conditions obtained by changing the verification conditions in the original preset pre-update verification. The pre-update verification is obtained by removing the verification conditions corresponding to the modified conditions from the original preset pre-update verification. After the pre-update verification passes, the OTA update task is executed. That is, this embodiment also performs vehicle condition checks and pre-verifications before performing an OTA update. However, compared to existing vehicle OTA upgrade technologies, this embodiment pre-transfers some content from the pre-verification to the vehicle condition check process. During the vehicle condition check process, the vehicle does not enter a BOOT state where it can be used normally. The OTA update task is only executed after the pre-verification passes. It can be understood that because the content of the pre-update verification is reduced, the time the user cannot use the vehicle during the update process is also reduced. This shortens the perceived vehicle update cycle and improves the user's driving experience while performing pre-verification. Attached Figure Description

[0087] 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.

[0088] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0089] Figure 1 is a flowchart of the first embodiment of the OTA update method of this application;

[0090] Figure 2 is a schematic diagram of the first output scenario of the prompt information in the OTA update method of this application;

[0091] Figure 3 is a schematic diagram of the second output scenario of the prompt information in the OTA update method of this application;

[0092] Figure 4 is a flowchart of the second embodiment of the OTA update method of this application;

[0093] Figure 5 is a schematic diagram of the first structure corresponding to the OTA update device of this application;

[0094] Figure 6 is a schematic diagram of the second structure corresponding to the OTA update device of this application;

[0095] Figure 7 is a flowchart of the third embodiment of the OTA update method of this application;

[0096] Figure 8 is a flowchart of the fourth embodiment of the OTA update method of this application;

[0097] Figure 9 is a flowchart of the fifth embodiment of the OTA update method of this application;

[0098] Figure 10 is a flowchart of the sixth embodiment of the OTA update method of this application;

[0099] Figure 11 is a schematic diagram of the OTA update device of this application;

[0100] Figure 12 is a flowchart of the seventh embodiment of the OTA update method of this application;

[0101] Figure 13 is a schematic diagram of the interface corresponding to the custom appointment upgrade mode in the OTA update method of this application;

[0102] Figure 14 is a flowchart of the eighth embodiment of the OTA update method of this application;

[0103] Figure 15 is a schematic diagram of the interface corresponding to the recommended upgrade mode in the OTA update method of this application;

[0104] Figure 16 is a schematic diagram of the OTA update device of this application;

[0105] Figure 17 is a schematic diagram of the device structure of the hardware operating environment involved in the OTA update method in this application embodiment;

[0106] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0107] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0108] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0109] OTA (Over-The-Air) refers to remote system software updates via the internet. As OTA technology becomes increasingly prevalent in new energy vehicles, OEMs are striving to optimize OTA performance and reduce its time consumption. In related vehicle OTA upgrade technologies, a pre-verification process is typically performed to ensure successful upgrades. It's important to note that this pre-verification process also takes time, and during this time, the vehicle will enter BOOT mode (in which the user cannot use the vehicle normally). Users will consider the time spent on pre-verification as the time required for the OTA upgrade. Therefore, in practical applications, the aforementioned vehicle OTA upgrade technologies tend to have longer upgrade times, thus impacting the user's vehicle experience.

[0110] The main solution of this application embodiment is as follows: after receiving an OTA update task, the current vehicle status is obtained; if the current vehicle status meets preset vehicle conditions, the vehicle is subjected to pre-update verification, wherein the preset vehicle conditions include modified conditions obtained by changing the verification conditions in the preset original pre-update verification, and the pre-update verification is obtained by removing the verification conditions corresponding to the modified conditions in the preset original pre-update verification; after the pre-update verification passes, the OTA update task is executed.

[0111] In this embodiment, before performing an OTA update, the vehicle also undergoes a vehicle condition check and pre-verification. However, compared to existing vehicle OTA upgrade technologies, this embodiment pre-transfers some content from the pre-verification process to the vehicle condition check process, and executes the OTA update task only after the pre-verification is passed. It can be understood that because the content of the pre-verification is reduced, the time the user is unable to use the vehicle during the update process is also reduced. This shortens the perceived vehicle update cycle and improves the user's driving experience while still performing pre-verification.

[0112] The execution subject of this embodiment can be a computing service device with data processing, network communication and program execution functions, such as a cloud platform, computer, mobile phone, etc., or a vehicle capable of performing the above functions.

[0113] Based on this, this application provides an OTA update method. Referring to FIG1, it is a flowchart of the first embodiment of the OTA update method of this application.

[0114] In this embodiment, the OTA update method includes steps S10 to S30:

[0115] Step S10: After receiving the OTA update task, obtain the current vehicle status;

[0116] In this embodiment, the above-described OTA update method is typically applied to vehicles. OTA update tasks are generally used to update the software system on a vehicle, and these tasks can be sent from the cloud associated with the vehicle. Typically, an OTA update task carries update data packages for each update unit in the vehicle; an update unit refers to the ECU (Electronic Control Unit) that needs to be updated in this OTA update task. Furthermore, the OTA update task may also carry other information as needed, such as an update list including the required update duration for each update unit. The specific details can be set by technical personnel and will not be elaborated here.

[0117] For example, a vehicle can receive an OTA update task from the cloud and then obtain its current vehicle status. This current vehicle status is used for vehicle condition checks, which is one of the steps to determine whether the vehicle meets the update requirements. Before preparing for an update, the vehicle needs user authorization (i.e., the user must agree to the vehicle update). For instance, after receiving an OTA update task, the vehicle's infotainment system can display an upgrade (update) prompt, which may include options for immediate upgrade and scheduled upgrade. If the user selects the immediate upgrade option, the vehicle can begin preparations for the upgrade; if the user selects the scheduled upgrade option, the vehicle needs to wait until the scheduled time slot before preparing for the upgrade. The specific content of the obtained current vehicle status is determined by the preset vehicle conditions that need to be checked later. For example, if the preset vehicle conditions in subsequent steps include the vehicle speed being less than a preset speed, then the obtained current vehicle status includes the vehicle's speed; if the preset vehicle conditions include the vehicle being in park, then the obtained current vehicle status includes the vehicle's gear information.

[0118] Step S20: If the current vehicle status meets the preset vehicle conditions, perform a pre-update verification on the vehicle. The preset vehicle conditions include modified conditions obtained by changing the verification conditions in the preset original pre-update verification. The pre-update verification is obtained by removing the verification conditions corresponding to the modified conditions in the preset original pre-update verification.

[0119] During the vehicle condition check, the vehicle does not enter the BOOT state. Therefore, the vehicle can be used normally by the user during this phase. When the vehicle is not in BOOT state during the condition check, signal interaction is conducted via application messages. Once the vehicle enters BOOT state, the FOTA Master (Firmware Over-the-Air Master) in the vehicle performs pre-verification, update, and post-verification. However, the FOTA Master running in BOOT state cannot collect application message signals; it primarily receives diagnostic messages, such as DOIP (Diagnostic over Internet Protocol) messages. Therefore, the vehicle condition check and pre-verification processes can be separated before the update. Furthermore, the vehicle condition check phase does not affect normal vehicle use; therefore, the time spent on the vehicle condition check phase is not included in the overall update cycle for the user.

[0120] For example, after obtaining the current vehicle status, the current vehicle status is compared with preset vehicle conditions to determine whether the current vehicle status meets the preset vehicle conditions. If the current vehicle status meets the preset vehicle conditions, a pre-update check is performed; otherwise, the vehicle condition check fails. The preset vehicle conditions include modified conditions derived from changes to the verification conditions in the original preset pre-check. The pre-update check is determined by removing the verification conditions corresponding to the modified conditions from the original preset pre-check. That is, in this embodiment, some verification conditions in the original preset pre-check are changed into conditions in the preset vehicle conditions (i.e., the modified conditions mentioned above). Alternatively, the original preset pre-check after removing the verification conditions corresponding to the modified conditions can be directly used as the pre-update check. The modified conditions can be conditions such as vehicle battery level being greater than a preset battery level or normal network operation (vehicle battery level greater than a preset battery level and normal network operation were originally verification conditions in the original preset pre-check). In addition to modified conditions, the preset vehicle conditions can also include conditions such as vehicle speed being less than a preset speed, vehicle being in parking gear, and scene mode being off. The current vehicle status can be determined by preset vehicle conditions, so the specific vehicle status will not be elaborated here. Additionally, it should be noted that in this embodiment, some content previously placed in the pre-verification stage of the relevant vehicle OTA upgrade technology has been moved to the vehicle condition check process. This includes information such as whether the vehicle's battery level is greater than a preset level and whether the network is functioning normally. This minimizes the amount of content required for pre-verification, reducing the time the user is unable to use the vehicle during the upgrade process. Thus, while performing pre-verification, the perceived vehicle update cycle is shortened.

[0121] Furthermore, during the pre-update verification process, vehicle information can be obtained based on the verification conditions specified in the pre-update verification. This vehicle information is then compared with the verification conditions. If the verification conditions are met, the vehicle passes the pre-update verification. The specific verification conditions for the pre-update verification can be set by technical personnel.

[0122] Step S30: After the pre-update verification passes, the OTA update task is executed.

[0123] For example, if a vehicle passes the pre-update verification, it means the vehicle is ready for an OTA update, and the OTA update task can then be executed. The OTA update process may include: backing up the current system so that it can be restored to its original state in case of update failure; system installation; decompressing the update files (decrypting the update files if necessary); and writing the new software code into the vehicle's ECU (Electronic Control Unit) or other modules that need updating. Furthermore, after installation, installation verification (or post-verification) may be required. During both the installation and post-verification processes, the vehicle is in BOOT mode, and the user will not be able to use the vehicle normally. It should be noted that the specific steps in executing the OTA update task can be set by technical personnel according to actual needs, and will not be elaborated here.

[0124] In this embodiment, upon receiving an OTA update task, the current vehicle status is obtained. If the current vehicle status meets preset vehicle conditions, a pre-update verification is performed on the vehicle. The preset vehicle conditions include modified conditions obtained by changing the verification conditions in the original preset pre-update verification. The pre-update verification is obtained by removing the verification conditions corresponding to the modified conditions from the original preset pre-update verification. After the pre-update verification passes, the OTA update task is executed. That is, this embodiment also performs vehicle condition checks and pre-verifications before performing an OTA update. However, compared to existing vehicle OTA upgrade technologies, this embodiment pre-transfers some content from the pre-verification to the vehicle condition check process and executes the OTA update task after passing the pre-verification. It can be understood that because the content of the pre-update verification is reduced, the time the user cannot use the vehicle during the update process is also reduced. This shortens the perceived vehicle update cycle and improves the user's driving experience while performing pre-verification.

[0125] In one embodiment, prior to the step of performing a pre-update verification on the vehicle, the method includes:

[0126] Determine the execution time for the vehicle to complete the OTA update task; if the execution time is less than or equal to the verification time required to perform the pre-update verification, skip the pre-update verification and execute the OTA update task; if the execution time is greater than the vehicle pre-update verification time, then perform the step of performing the pre-update verification on the vehicle.

[0127] For example, in practical applications, the cloud can pre-calculate the execution time of the OTA update task and include this execution time as information carried in the OTA update task. After receiving the OTA update task, the vehicle can directly obtain the execution time from the OTA update task. Alternatively, the cloud can only include the update time required for each update unit as information carried in the OTA update task. After receiving the OTA update task, the vehicle can extract the update time of each update unit from the OTA update task and calculate the execution time of the OTA update task based on each update time. In the case of serial updates, the execution time can be calculated by accumulating the update times. In the case of parallel updates, the execution time can be determined by the longest update time. The verification time required for the pre-update verification can be obtained through testing. That is, the time required for the vehicle to complete the pre-update verification multiple times can be counted, and the average time can be used as the verification time. Then, the execution time and the verification time are compared to determine whether to skip the pre-update verification part.

[0128] Pre-update verification ensures a smooth update (upgrade) process, preventing updates from failing midway and extending the overall update cycle. Therefore, when the actual update duration is long, additional time can be allocated for pre-update verification to mitigate this risk. However, if the pre-update verification time exceeds the required update time, this time will inevitably be longer than the time lost due to update failures. In this case, the pre-update verification will not reduce the overall update cycle. Instead, skipping the pre-update verification and discarding invalid operations can reduce the overall update (upgrade) cycle time, thus improving the user experience.

[0129] In one embodiment, after the step of obtaining the current vehicle status, the method further includes steps S01 to S02:

[0130] Step S01: If the current vehicle state does not meet the preset vehicle conditions, determine the prompt information based on the target state information in the current vehicle state that does not meet the preset vehicle conditions.

[0131] Step S02: The prompt information is output through the vehicle's infotainment screen.

[0132] For example, since the process of generating prompts based on each target state information is roughly similar, this embodiment will use one target state information as an example for explanation. For instance, for any target state information in the current vehicle state that does not meet the preset vehicle conditions, after the vehicle inspection determines that the target state information is obtained, a prompt information is generated in real time based on the target state information, and the prompt information is output to the user through the vehicle's onboard unit, so that the user can handle it in a timely manner.

[0133] Referring to Figure 2, which is a schematic diagram of the first output scenario of the prompt information in this application, if the preset vehicle conditions include the vehicle being in park and the vehicle currently in motion, the prompt information interface shown in Figure 2 can be output through the vehicle's infotainment screen. Referring to Figure 3, which is a schematic diagram of the second output scenario of the prompt information in this application, if the preset vehicle conditions include the vehicle scene mode being off and the scene mode currently being on, the prompt information interface shown in Figure 3 can be output through the vehicle's infotainment screen.

[0134] By moving some aspects of the vehicle OTA upgrade technology from the pre-verification stage to the vehicle condition check process, not only can the pre-verification time be reduced, but the vehicle can also be adjusted to meet preset vehicle conditions more promptly. For example, because pre-verification enters the BOOT phase, the vehicle's infotainment system is in a black screen state and cannot output information. Therefore, when problems occur during verification, users are unaware of the cause and can only view the problem on the mobile app after the pre-verification process is complete, impacting the user experience and preventing timely problem resolution. However, by moving some content from the pre-verification process to the vehicle condition check section, any problems (i.e., unmet preset vehicle conditions) can be directly displayed on the large screen, allowing users to immediately understand the reason affecting the OTA upgrade and address it promptly.

[0135] In one embodiment, the step of performing pre-update verification on the vehicle includes steps S21 to S22:

[0136] Step S21: Obtain the vehicle information of the vehicle;

[0137] Step S22: If the vehicle information meets the verification conditions of the pre-update verification, the pre-update verification is determined to be passed. The verification conditions of the pre-update verification include at least one of the following: the vehicle has obtained update authorization; the vehicle's identity identifier is the same as the task vehicle identifier of the OTA update task; there are no occupants in the vehicle; the vehicle's power supply is active; the vehicle's three-electric system is in OTA state; the vehicle's anti-theft system is normal; the vehicle is in full vehicle lockout; each update unit in the vehicle corresponding to the OTA update task is online; the preset update unit in each update unit has received the update file key; the vehicle's management module is in OTA state; and the vehicle's fault codes have been cleared. Each update unit is an electronic control unit that controls the vehicle.

[0138] For example, the steps of pre-update verification in this embodiment include the vehicle obtaining its own vehicle information. The specific content of the vehicle information is determined by the verification conditions in the pre-update verification. If the verification condition includes that there are no occupants in the vehicle, the vehicle information may include the number of occupants in the vehicle. If the verification condition includes that the vehicle's identity identifier is the same as the task vehicle identifier of the OTA update task, the vehicle information may include the vehicle's identity identifier, etc., which will not be elaborated here.

[0139] The acquired vehicle information is compared with the verification conditions before the update. If the vehicle information meets the verification conditions before the update, the update verification is considered successful. These verification conditions include at least one of the following: the vehicle has been authorized for update; the vehicle's identification identifier matches the task vehicle identifier of the OTA update task; there are no occupants in the vehicle; the vehicle's power supply is active; the vehicle's three-electric system is in OTA mode; the vehicle's anti-theft system is functioning normally; the vehicle is fully locked; all update units corresponding to the OTA update task are online; the preset update units in each update unit have received the update file key; the vehicle's management module is in OTA mode; and the vehicle's fault codes have been cleared. Each update unit refers to an electronic control unit that controls the vehicle and requires updating, such as the engine control unit, automatic transmission control unit, body control module, electronic stability control unit, battery management unit, vehicle controller, and hydraulic control unit, etc., which will not be elaborated further here. It should be noted that the verification conditions can be freely combined by technicians based on the above conditions, or, to mitigate risks, it is preferable to include all of the above conditions in the verification conditions.

[0140] Furthermore, the verification conditions are: the vehicle has already obtained update authorization. The corresponding verification process is as follows: the vehicle outputs an option to update via the HMI (Human-Machine Interface). Accordingly, update authorization is obtained after the user selects to agree to the update. It is worth noting that in practical applications, after the user clicks to install the upgrade, a "regret period" is set. During this period, the user can unlock and drive the vehicle. However, the OTA upgrade task will not proceed during this time; it will be postponed until the user confirms the upgrade installation again.

[0141] Verification condition: The vehicle's identity identifier is the same as the task vehicle identifier of the OTA update task. The corresponding verification process is to check whether the vehicle's UUID (Universally Unique Identifier) ​​is the same as the UUID in the cloud, i.e., the task vehicle identifier. If they are inconsistent, the task is invalid and needs to be reported as a failure.

[0142] Verification condition: No occupants are present in the vehicle. The corresponding verification process is a living entity detection. This process is to prevent the vehicle from failing during OTA upgrades if someone is inside. If someone is present, the vehicle horn will sound. This is because, in practical applications, it is not recommended to have someone in the vehicle during OTA upgrades, as someone inside the vehicle performing actions that cannot be prohibited (i.e., high-privilege operations, such as braking) may cause the vehicle upgrade to fail. This verification condition can be set according to the functional conditions of different projects and vehicle models (some models may have living entity detection configured).

[0143] Verification conditions: The vehicle's power supply must be in an active state. The corresponding verification process is to check the power mode. This process checks the vehicle's power mode. After the regret period ends, the vehicle's power mode must be inactive (active state). If the power mode does not meet the requirements, the OTA update task will be postponed.

[0144] Verification conditions: The vehicle's three-electric system enters OTA (Over-The-Air) status. The corresponding verification process is as follows: the powertrain system enters OTA status. This process involves the FOTA Master sending diagnostic commands to the domain controllers of the three-electric system, causing it to enter OTA status. The "three-electric system" typically refers to the three main electrical systems of an electric vehicle: Battery Management System (BMS), Microcontroller Unit (MCU), and Vehicle Control Unit (VCU). When these systems enter OTA status, it means the vehicle is receiving or preparing to receive a remote software update from the manufacturer.

[0145] Verification conditions: The vehicle's anti-theft system is normal. The corresponding verification process is to check whether the anti-theft system is normal. This process involves FOTA Master sending diagnostic commands to the vehicle's domain controller to check the anti-theft status of the entire vehicle.

[0146] Verification conditions: The vehicle is in a fully locked state. The corresponding verification process is to check whether the entire vehicle is locked. This process involves FOTA Master sending diagnostic commands to the vehicle's domain controller to check whether all locks of the entire vehicle are in a locked state.

[0147] Verification conditions: Each update unit in the vehicle corresponding to the OTA update task is online. The corresponding verification process is to check the online status of the vehicle ECU. This process involves the FOTA Master sending diagnostic commands to the vehicle ECU to confirm the status of the vehicle ECU. It is not that the ECU not in this OTA task (i.e., non-update unit, while the ECU in this OTA task is the update unit) is offline. This does not affect the task and the OTA upgrade task can be performed normally.

[0148] Verification conditions: The preset update unit in each update unit has received the update file key. The corresponding verification process is to check whether there is a distributed ECU (i.e., a preset update unit) in this OTA task. If the current OTA has a distributed ECU, then request the file key of the distributed ECU and then send the key to the distributed ECU.

[0149] Verification conditions: The vehicle's management module is in OTA mode and the vehicle's fault codes have been cleared. The corresponding verification process is to clear DTC (Diagnostic Trouble Code) preparation, which involves clearing the vehicle's existing DTC records.

[0150] In addition to the above, the verification conditions before the update may also include: checking the OTA pre-sales / after-sales status, which involves checking the vehicle's status, categorized as pre-sales or after-sales. If the vehicle is a pre-sales vehicle, the verification condition that the vehicle's identity identifier matches the OTA update task's vehicle identifier is not required; checking the network connection, which mainly checks if the vehicle's network status is normal. If the network is poor or disconnected, the OTA task cannot proceed and will be delayed; and checking the battery pack charge, i.e., the main battery charge, to ensure that the vehicle's battery pack charge is not too low, as OTA upgrades also consume power, preventing potential risks to the user's subsequent vehicle use if the vehicle's battery charge is already low.

[0151] The aforementioned pre-update verification is a pre-update verification that can be skipped under specific conditions. Alternatively, in this embodiment, a non-skippable pre-update vehicle verification can be set, namely, data file verification. This process mainly verifies whether the downloaded data is valid, including the size of the downloaded data, and that the encryption type of the data file is correct, including decrypting the VBF (Vehicle Bulletin File) file.

[0152] Furthermore, if the vehicle information does not meet the verification conditions before the update, the OTA update task can be postponed. The unsatisfactory verification conditions will be output after the pre-update verification is completed.

[0153] Referring to Figure 4, which illustrates a first embodiment of the OTA update method based on this application, a second embodiment of this application is proposed. Contents identical or similar to those in the above embodiments can be found in the preceding description and will not be repeated hereafter. The steps for performing the OTA update task include steps S31 to S33:

[0154] Step S31: For any one of the update units corresponding to the OTA update task, determine the target update data corresponding to the update unit;

[0155] Step S32: Write the target update data to the data storage area of ​​the update unit, and verify the data stored in the data storage area after writing is completed;

[0156] Step S33: After the verification is passed, the update unit is updated.

[0157] The aforementioned OTA update task typically involves updating multiple ECUs on the vehicle, i.e., multiple control units. The control unit that needs to be updated is called the update unit. Furthermore, since the processing method for each update unit is the same, this embodiment will use one update unit as an example for explanation.

[0158] For example, for any one of the update units corresponding to an OTA update task, the target update data corresponding to that update unit is determined. Upon receiving an OTA update task, a data update package can be downloaded synchronously. Different identifiers can be set for data packets targeting different update units. Therefore, the target update data corresponding to the aforementioned update unit can be found from the downloaded data update package using the identifier pre-set for that update unit. Then, the update unit is flashed based on this target update data, that is, the target update data is written to the data storage area of ​​the aforementioned update unit. After the writing is completed, the data stored in the data storage area is verified to ensure that the writing is error-free. For example, the verification method can be CRC (Cyclic Redundancy Check). After the verification passes, it can be indicated that the update unit has completed the update. Each update unit can be updated by referring to the above process, so it will not be elaborated further here.

[0159] In one embodiment, after the step of determining the target update data corresponding to the update unit, the method includes step S34:

[0160] Step S34: If the target update data fails to be written to the data storage area, or the data stored in the data storage area fails to be verified, then the historical data in the data backup area corresponding to the update unit is used to overwrite the data stored in the data storage area to roll back the system version of the update unit.

[0161] For example, if an error occurs when writing the target update data to the data storage area of ​​the update unit, the writing of the target update data to the data storage area can be considered a failure. Alternatively, after an error occurs, the target update data can be re-attempted to be written to the data storage area. After a preset number of attempts, the writing of the target update data to the data storage area is determined to have failed. Furthermore, if the data stored in the data storage area fails verification, it can be considered a data verification failure. Alternatively, after the data stored in the data storage area fails verification, the writing and verification can be re-attempted. After a preset number of attempts, the data access to the storage area is determined to have failed. In the event of failure to write the target update data to the data storage area, or failure to verify the data stored in the data storage area, the update unit uses historical data in the data backup area to overwrite the data stored in the data storage area, thereby rolling back the system version of the update unit. This ensures that even if the update unit fails to update, it can still provide its original functionality using the old system version. Additionally, before writing the target update data to the data storage area, the data in the data storage area can be backed up to the data backup area to form historical data.

[0162] In one embodiment, before the step of writing the target update data to the data storage area of ​​the update unit, the method includes steps S301 to S302:

[0163] Step S301: Determine the collaborative unit related to the update unit based on the preset collaborative work unit mapping table;

[0164] Step S302: Disable the unit function of the update unit and the unit function of the coordination unit, wherein the unit function of the update unit is re-enabled after the update unit finishes updating and the coordination unit that needs to be updated finishes updating.

[0165] In this embodiment, to avoid mutual interference between the upgraded control unit (i.e., the update mentioned above) and the control unit that does not need to be upgraded during the upgrade process, the unit function of the update unit will be adaptively turned off in this embodiment.

[0166] For example, before actually writing the target update data of the update unit to the data storage area of ​​the update unit, it is necessary to determine the related units that have a cooperative relationship with the update unit, that is, the aforementioned cooperative units. The cooperative units related to the update unit can be determined by a preset cooperative working unit mapping table. The preset cooperative working unit mapping table can be set by technicians according to the relationship between units in the vehicle. Taking the core unit in the vehicle - the engine control unit - as an example, the transmission control unit, the braking control unit, the electronic stability program control unit, and the battery management system in the vehicle have a cooperative relationship with the engine control unit. Accordingly, the cooperative working relationship between the engine control unit and the above-mentioned units and systems can be recorded in the preset cooperative working unit mapping table.

[0167] After identifying the coordinating units, disable the unit functions of both the update unit and the coordinating units. This prevents mutual interference between the update unit and the coordinating units during the upgrade process, such as a coordinating unit affecting the update unit's update or the update unit causing errors in the coordinating units during the upgrade. Once the update unit has completed its update and the coordinating units that require updates have finished updating, re-enable the unit function of the update unit. This also allows for adaptive use of the coordinating unit's unit functions.

[0168] This application also provides an OTA update device, as shown in FIG5, the OTA update device includes:

[0169] The acquisition module 10 is used to acquire the current vehicle status after receiving an OTA update task;

[0170] The verification module 20 is used to perform a pre-update verification on the vehicle when the current vehicle status meets the preset vehicle conditions. The preset vehicle conditions include modified conditions obtained by changing the verification conditions in the preset original pre-update verification. The pre-update verification is obtained by removing the verification conditions corresponding to the modified conditions in the preset original pre-update verification.

[0171] The execution module 30 is used to execute the OTA update task after the pre-update verification is passed.

[0172] In one embodiment, referring to FIG6, the OTA update device further includes a prompting module 40, the prompting module 40 being used for:

[0173] If the current vehicle status does not meet the preset vehicle conditions, a prompt message is determined based on the target status information in the current vehicle status that does not meet the preset vehicle conditions.

[0174] The prompt message is displayed on the vehicle's infotainment screen.

[0175] In one embodiment, the verification module 20 is further configured to:

[0176] Obtain the vehicle information of the vehicle;

[0177] If the vehicle information meets the verification conditions of the pre-update verification, the pre-update verification is determined to be passed. The verification conditions of the pre-update verification include at least one of the following: the vehicle has obtained update authorization; the vehicle's identity identifier is the same as the task vehicle identifier of the OTA update task; there are no occupants in the vehicle; the vehicle's power supply is active; the vehicle's three-electric system is in OTA state; the vehicle's anti-theft system is normal; the vehicle is in full vehicle lockout; each update unit in the vehicle corresponding to the OTA update task is online; the preset update unit in each update unit has received the update file key; the vehicle's management module is in OTA state; and the vehicle's fault codes have been cleared. Each update unit is an electronic control unit that controls the vehicle.

[0178] In one embodiment, the execution module 30 further includes:

[0179] For any one of the update units corresponding to the OTA update task, determine the target update data corresponding to the update unit;

[0180] The target update data is written to the data storage area of ​​the update unit, and the data stored in the data storage area is verified after the writing is completed;

[0181] After the verification is passed, the update unit is updated.

[0182] In one embodiment, the execution module 30 further includes:

[0183] If the target update data fails to be written to the data storage area, or if the data stored in the data storage area fails to be verified, then the historical data in the data backup area corresponding to the update unit is used to overwrite the data stored in the data storage area, so as to roll back the system version of the update unit.

[0184] In one embodiment, the execution module 30 further includes:

[0185] The collaborative units associated with the update unit are determined based on a preset collaborative work unit mapping table;

[0186] The unit functions of the update unit and the coordination unit are disabled, wherein the unit functions of the update unit are re-enabled after the update unit finishes updating and the coordination unit that needs to be updated finishes updating.

[0187] The OTA update device provided in this application, employing the OTA update method in the above embodiments, can solve the technical problem of long upgrade times in practical applications of related vehicle OTA upgrade technologies. Compared with the prior art, the beneficial effects of the OTA update device provided in this application are the same as those of the OTA update method provided in the above embodiments, and other technical features in the OTA update device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0188] The main solution of this application embodiment is: receiving an OTA update task, determining the execution time for the vehicle to complete the OTA update task; if the execution time is less than or equal to the verification time required to perform a preset vehicle pre-update verification, skipping the preset vehicle pre-update verification; and executing the OTA update task.

[0189] In this application, upon receiving an OTA update task, the vehicle does not directly perform pre-verification as in the aforementioned related vehicle OTA upgrade technologies. Instead, it first determines the execution time of the OTA update task and compares it with the verification time required for a preset vehicle update pre-verification. If the execution time is less than or equal to the verification time, the preset vehicle update pre-verification can be skipped, and the OTA update task can be executed directly. It is understandable that the purpose of the preset vehicle update pre-verification is to ensure that the vehicle can be updated (upgraded) normally, avoiding the problem of the entire update cycle being lengthened due to failure during the update. Therefore, when the actual update time is long, additional time can be spent on pre-verification to reduce the risk of the entire update cycle being lengthened. However, if the verification time of the pre-verification is longer than the time required for the update, the pre-verification time will inevitably be longer than the time lost due to failure during the update. Therefore, the pre-verification operation performed in this case cannot achieve the benefit of reducing the entire update cycle. Accordingly, skipping the pre-verification part and discarding invalid operations can reduce the overall update (upgrade) cycle time of the vehicle, thereby improving the user's driving experience.

[0190] The execution subject of this embodiment can be a computing service device with data processing, network communication and program execution functions, such as a cloud platform, computer, mobile phone, etc., or a vehicle capable of performing the above functions.

[0191] Based on this, this application provides an OTA update method. Referring to FIG7, it is a flowchart of the third embodiment of the OTA update method of this application.

[0192] In this embodiment, the OTA update method includes steps S10 to S30:

[0193] Step S10: Receive OTA update task and determine the execution time for the vehicle to complete the OTA update task;

[0194] In this embodiment, the above-described OTA update method is typically applied to vehicles. Vehicles can receive OTA update tasks sent from the cloud; that is, the cloud can send OTA update tasks to different vehicles. The OTA update task usually carries update data packets for each update unit in the vehicle, and the update unit refers to the ECU (Electronic Control Unit) in the vehicle that needs to be updated in this OTA update task. In addition, the OTA update task may also carry other information as needed, such as an update list including the required update duration for each update unit (i.e., the partial update duration appearing in subsequent steps).

[0195] For example, a vehicle can receive an OTA update task sent by the cloud and then determine the execution duration of the OTA update task. In practical applications, the cloud can also pre-calculate the execution duration of the OTA update task and include this execution duration as information carried in the OTA update task. After receiving the OTA update task, the vehicle can directly obtain the execution duration from the OTA update task. Alternatively, the cloud can only include the update duration required by each update unit as information carried in the OTA update task. After receiving the OTA update task, the vehicle can extract the update duration of each update unit from the OTA update task and calculate the execution duration of the OTA update task based on each update duration. In the case of serial updates, the execution duration can be calculated by accumulating the update durations. In the case of parallel updates, the execution duration can be determined by the longest update duration.

[0196] Step S20: If the execution time is less than or equal to the verification time required to perform the preset vehicle update pre-verification, skip the preset vehicle update pre-verification.

[0197] The aforementioned pre-update vehicle verification (also known as pre-update verification) refers to a self-check operation performed before the official update to ensure that the vehicle can complete the update (or upgrade) normally. For example, the pre-update vehicle verification may include checking whether anyone is in the vehicle, whether each update unit is online, and whether the vehicle is locked. The specific verification content can be set by technical personnel according to actual needs, and will not be elaborated here. The verification time required for the aforementioned pre-update vehicle verification can be obtained through testing; that is, the time required for the vehicle to complete the pre-update vehicle verification multiple times can be statistically analyzed, and the average time can be used as the verification time.

[0198] For example, after determining the execution time of the OTA update task, the execution time can be compared with the verification time. If the execution time is less than or equal to the verification time, the preset vehicle pre-update verification can be skipped, thereby reducing the overall cycle time of vehicle OTA updates and improving the user's vehicle usage experience.

[0199] Step S30: Execute the OTA update task.

[0200] For example, after skipping the aforementioned pre-update vehicle verification, the OTA update task can be executed directly. The OTA update process may include: backing up the current system so that it can be restored to its original state in case of update failure; system installation, decompressing the update files (which may be decrypted if necessary), and writing the new software code into the vehicle's ECU (Electronic Control Unit) or other modules requiring updates. Furthermore, after installation, installation verification (or post-verification) may be required. During both the installation and post-verification processes, the vehicle is in BOOT mode, and the user will not be able to use the vehicle normally. The specific steps in executing the OTA update task can also be set by technicians according to actual needs, and will not be elaborated here.

[0201] In this embodiment, after receiving an OTA update task, the vehicle does not perform pre-verification as described in the aforementioned related vehicle OTA upgrade technologies. Instead, it first determines the execution time of the OTA update task and compares it with the verification time required for a preset vehicle update pre-verification. If the execution time is less than or equal to the verification time, the preset vehicle update pre-verification can be skipped, and the OTA update task can be executed directly. It is understood that the purpose of the preset vehicle update pre-verification is to ensure that the vehicle can be updated (upgraded) normally, avoiding the problem of the entire update cycle being lengthened due to failure during the update. Therefore, when the actual update time is long, additional time can be spent on pre-verification to reduce the risk of the entire update cycle being lengthened. However, if the verification time of the pre-verification is longer than the time required for the update, the pre-verification time will inevitably be longer than the time lost due to the failure during the update. Therefore, the pre-verification operation performed in this case cannot achieve the benefit of reducing the entire update cycle. Accordingly, skipping the pre-verification part and discarding invalid operations can reduce the overall update (upgrade) cycle time of the vehicle, thereby improving the user's driving experience.

[0202] Referring to Figure 8, which is a flowchart illustrating a fourth embodiment of this application based on the third embodiment, the same or similar content as the above embodiments can be referred to the above description and will not be repeated hereafter. After the step of receiving the OTA update task, the method includes steps S01 to S03:

[0203] Step S01: Obtain the current vehicle status of the vehicle;

[0204] Step S02: If the current vehicle status meets the preset vehicle conditions, perform the step of determining the execution time for the vehicle to complete the OTA update task.

[0205] Step S03: If the current vehicle state does not meet the preset vehicle conditions, output a prompt message based on the target state information in the current vehicle state that does not meet the preset vehicle conditions.

[0206] In this embodiment, a vehicle condition check is performed before the vehicle is officially updated to ensure that the update can be completed normally (or safely). During the vehicle condition check, the vehicle does not enter the BOOT state; therefore, the vehicle can be used normally by the user during this phase. It is worth noting that the vehicle is not in the BOOT state during the condition check, and signal interaction is conducted via application messages. When the vehicle enters the BOOT state, the FOTA Master (Firmware Over-the-Air Master) in the vehicle performs pre-verification, update, and post-verification. However, the FOTA Master running in the BOOT state cannot collect application message signals; it primarily receives diagnostic messages, such as DOIP (Diagnostic over Internet Protocol) messages. Accordingly, the vehicle needs to undergo a vehicle condition check and pre-verification process before the update. Since the vehicle condition check phase does not affect normal user operation, the time spent on this phase is not included in the overall update cycle for the user.

[0207] For example, after a vehicle receives an OTA update task, a vehicle condition check can be performed first, including obtaining the vehicle's current status. The specific vehicle status can be determined by the vehicle conditions to be checked, and the current vehicle status is communicated within the vehicle via application messages. The obtained current vehicle status is compared with preset vehicle conditions. If the current vehicle status meets the preset vehicle conditions, the vehicle condition check is considered passed; otherwise, it fails. The preset vehicle conditions include modified conditions derived from changes to the verification items (i.e., verification conditions) in the preset original pre-check. The preset vehicle update pre-check is determined by removing the verification items corresponding to the modified conditions from the preset original pre-check. In this embodiment, some verification items in the preset original pre-check are transformed into conditions in the preset vehicle conditions (i.e., the modified conditions mentioned above). Alternatively, the preset original pre-check after removing the verification items corresponding to the modified conditions can be directly used as the preset vehicle update pre-check. The modified conditions can be, for example, vehicle battery level exceeding a preset battery level or normal network operation (vehicle battery level exceeding a preset battery level and normal network operation were originally verification items in the preset original pre-check). In addition to changing the conditions, the preset vehicle conditions can also include conditions such as the vehicle speed being less than the preset speed, the vehicle being in parking gear, and the scene mode being turned off.

[0208] For example, if the preset vehicle conditions include the vehicle speed being less than a preset speed, then the obtained current vehicle status includes the vehicle's speed; if the preset vehicle conditions include the vehicle being in park, then the obtained current vehicle status includes the vehicle's gear information. That is, the obtained current vehicle status can be determined by the preset vehicle conditions, so the specific vehicle status will not be elaborated here. Furthermore, it should be noted that in this embodiment, some content previously placed in the pre-verification stage of the relevant vehicle OTA upgrade technology has been moved to the vehicle condition check process, such as whether the vehicle's battery level is greater than a preset level and whether the network is functioning normally. This minimizes the content of the pre-verification, i.e., reduces the verification time, thereby shortening the overall update cycle while still performing pre-verification.

[0209] For example, if the current vehicle status does not meet preset vehicle conditions, a prompt message can be output based on the target status information of the current vehicle status that does not meet the preset vehicle conditions. For instance, if the vehicle's battery level is less than or equal to a preset battery level, the target status information could be the vehicle's battery level. Correspondingly, the output prompt message would be "Vehicle battery level is too low and does not meet the condition of having a battery level greater than the preset battery level," allowing the user to charge the vehicle accordingly. The specific format of the prompt message can be set by technical personnel according to actual needs and should be related to the target status information; this will not be elaborated upon here.

[0210] In one embodiment, the step of outputting a prompt message based on the target state information that does not meet the preset vehicle conditions in the current vehicle state includes step S003:

[0211] Step S003: For any target state information in the current vehicle state that does not meet the preset vehicle conditions, after determining the target state information, generate a prompt message in real time based on the target state information, and output the prompt message through the vehicle's infotainment screen.

[0212] For example, since the process of generating prompts based on each target status information is roughly similar, this embodiment will use one target status information as an example for explanation. For instance, for any target status information in the current vehicle status that does not meet the preset vehicle conditions, after the vehicle inspection determines that the target status information is obtained, a prompt is generated in real time based on the target status information, and the prompt is output to the user through the vehicle's onboard unit, so that the user can handle it in a timely manner.

[0213] By moving some aspects of the vehicle OTA upgrade technology from the pre-verification stage to the vehicle condition check process, not only can the pre-verification time be reduced, but the vehicle can also be adjusted to meet preset vehicle conditions more promptly. For example, because pre-verification enters the BOOT phase, the vehicle's infotainment system is in a black screen state and cannot output information. Therefore, when problems occur during verification, users are unaware of the cause and can only view the problem on the mobile app after the pre-verification process is complete, impacting the user experience and preventing timely problem resolution. However, by moving some content from the pre-verification process to the vehicle condition check section, any problems (i.e., unmet preset vehicle conditions) can be directly displayed on the large screen, allowing users to immediately understand the reason affecting the OTA upgrade and address it promptly.

[0214] Referring to Figure 9, which is a flowchart illustrating the fifth embodiment of this application based on the third and fourth embodiments, the same or similar content as the above embodiments can be referred to the above description and will not be repeated hereafter. After the step of receiving the OTA update task, the method further includes steps S40 to S50:

[0215] Step S40: If the execution time is longer than the vehicle pre-verification time, perform the preset vehicle update pre-verification.

[0216] Step S50: After the preset vehicle update pre-verification passes, the OTA update task is executed.

[0217] For example, if the execution time of the preset vehicle update pre-verification is longer than the vehicle pre-verification time, then the normal preset vehicle update pre-verification steps can be performed. It is understandable that, as mentioned above, the preset vehicle update pre-verification is used to avoid the problem of the entire update cycle being lengthened due to vehicle update failures. Correspondingly, when the execution time of an OTA update task is long, i.e., the update cycle is long, the time wasted due to an update failure may be far greater than the time spent on pre-verification. For example, suppose the vehicle OTA upgrade involves a lot of content and takes 10 minutes. In practical applications, if the vehicle OTA upgrade encounters a problem at the 9-minute mark and needs to be interrupted and restarted, then the 9 minutes spent are essentially wasted. However, if the pre-verification takes 2 minutes and ensures the vehicle can update normally, adding the pre-verification step is equivalent to incurring a 2-minute cost to avoid wasting 9 minutes. Conversely, if the vehicle OTA upgrade involves a small amount of content and only takes 1 minute, even if the upgrade fails at the 1-minute mark, the time cost is still less than the 2-minute cost of verification. Accordingly, after the pre-verification passes, the OTA update task can be executed.

[0218] In one embodiment, the step of performing the preset vehicle update pre-verification includes steps S41 to S42:

[0219] Step S41: Obtain the vehicle information of the vehicle;

[0220] Step S42: If the vehicle information meets the verification items of the preset vehicle pre-update verification, determine that the preset vehicle pre-update verification has passed. The verification items of the preset vehicle pre-update verification include at least one of the following: the vehicle has obtained update authorization; the vehicle's identity identifier is the same as the task vehicle identifier of the OTA update task; there are no occupants in the vehicle; the vehicle's power supply is active; the vehicle's three-electric system has entered OTA state; the vehicle's anti-theft system is normal; the vehicle is locked; each update unit in the vehicle corresponding to the OTA update task is online; the preset update unit in each update unit has received the update file key; the vehicle's management module has entered OTA state; and the vehicle's fault codes have been cleared.

[0221] For example, the steps of performing the pre-update verification of the vehicle in this embodiment include: the vehicle will obtain its own vehicle information, wherein the specific content of the vehicle information is determined by the verification items in the pre-update verification. If the verification item includes that there are no occupants in the vehicle, then the vehicle information may include the number of occupants in the vehicle. If the verification item includes that the vehicle's identity is the same as the task vehicle identity of the OTA update task, then the vehicle information may include the vehicle's identity, etc., which will not be described in detail here.

[0222] The acquired vehicle information is compared with the preset vehicle update pre-verification items. If the vehicle information meets the preset vehicle update pre-verification items, the preset vehicle update pre-verification is considered passed. The verification items include at least one of the following: the vehicle has been authorized for update; the vehicle's identification identifier matches the task vehicle identifier of the OTA update task; there are no occupants in the vehicle; the vehicle's power supply is active; the vehicle's three-electric system is in OTA mode; the vehicle's anti-theft system is functioning normally; the vehicle is fully locked; each update unit corresponding to the OTA update task is online; the preset update unit in each update unit has received the update file key; the vehicle's management module is in OTA mode; and the vehicle's fault codes have been cleared. It should be noted that the verification items can be freely combined by technical personnel based on the above conditions. To mitigate risks, it is preferable that the verification items include all of the above conditions.

[0223] Furthermore, the verification item confirms that the vehicle has been authorized to update. The corresponding verification process involves the vehicle displaying an option to update via the HMI (Human-Machine Interface). Upon the user's confirmation, update authorization is granted. It's worth noting that in practical applications, a "regret period" is set after the user clicks to install the upgrade. During this period, the user can unlock and drive the vehicle. However, the OTA upgrade will not proceed; instead, it will be delayed until the user confirms the upgrade installation again.

[0224] The vehicle's identity identifier must be the same as the vehicle identifier of the OTA update task. The corresponding verification process is to check whether the vehicle's UUID (Universally Unique Identifier) ​​is the same as the UUID of the task vehicle in the cloud. If they are not the same, the task is invalid and needs to be reported as a failure.

[0225] The verification item states that there are no occupants in the vehicle. The corresponding verification process is a vital sign detection. This process is to prevent the vehicle from being occupied during OTA upgrades. If someone is present, the vehicle horn will sound. This is because, in practical applications, it is not recommended for anyone to be in the vehicle during OTA upgrades, as someone performing actions that cannot be prohibited (i.e., high-privilege operations, such as braking) may cause the upgrade to fail. This verification item can be configured according to the functional conditions of different projects and vehicle models (some models may have vital sign detection configured).

[0226] The verification item is that the vehicle's power supply is in an active state. The corresponding verification process is to check the power mode. This process checks the vehicle's power mode. After the regret period ends, the vehicle's power mode must be inactive (active state). If the power mode does not meet the requirements, the OTA update task will be postponed.

[0227] The verification item verifies that the vehicle's three-electric system has entered OTA (Over-The-Air) status. The corresponding verification process is as follows: the powertrain system enters OTA status. This process involves the FOTA Master sending diagnostic commands to the domain controllers of the three-electric system, causing it to enter OTA status. The "three-electric system" typically refers to the three main electrical systems of an electric vehicle: the Battery Management System (BMS), the Microcontroller Unit (MCU), and the Vehicle Control Unit (VCU). When these systems enter OTA status, it means that the vehicle is receiving or preparing to receive a remote software update from the manufacturer.

[0228] The verification item indicates that the vehicle's anti-theft system is normal. The corresponding verification process is to check whether the anti-theft system is normal. This process involves FOTA Master sending diagnostic commands to the vehicle's domain controller to check the vehicle's anti-theft status.

[0229] The verification item indicates that the vehicle is fully locked. The corresponding verification process is to check whether the entire vehicle is locked. This process involves FOTA Master sending diagnostic commands to the vehicle's domain controller to check whether all locks on the vehicle are in a locked state.

[0230] The verification item states that each update unit in the vehicle corresponding to the OTA update task is online. The corresponding verification process is to check the online status of the vehicle ECU. This process involves the FOTA Master sending a diagnostic command to the vehicle ECU to confirm the status of the vehicle ECU. If an ECU not in this OTA task (i.e., a non-update unit, while an ECU in this OTA task is an update unit) is not online, it will not affect this task, and the OTA upgrade task can be performed normally.

[0231] The preset update unit in each update unit of the verification item has received the update file key. The corresponding verification process is to check whether there is a distributed ECU (i.e., a preset update unit) in this OTA task. If the current OTA is allocated a distributed ECU, then request the file key of the distributed ECU and then send the key to the distributed ECU.

[0232] The verification process involves checking if the vehicle's management module has entered OTA mode and if the vehicle's fault codes have been cleared. The corresponding verification process is to clear DTC (Diagnostic Trouble Code) preparation, which involves clearing the vehicle's existing DTC records.

[0233] In addition to the above, the pre-installed vehicle update verification items may also include: checking the OTA pre-sales / after-sales status, which involves checking the vehicle's condition, categorized as pre-sales or after-sales. If the vehicle is a pre-sales vehicle, the verification requirement that the vehicle's identity identifier matches the OTA update task's vehicle identifier is not required; checking network connectivity, which primarily checks the vehicle's network status; if the network is poor or disconnected, the OTA task cannot proceed and will be delayed; and checking battery pack charge, i.e., the main battery charge, to ensure the vehicle's battery pack charge is not too low, as OTA upgrades also consume power, preventing potential risks to users if the battery is already low during OTA updates.

[0234] The aforementioned pre-update vehicle verification is a pre-update verification that can be skipped under specific conditions. Alternatively, in this embodiment, a non-skippable pre-update vehicle verification can be set, namely, data file verification. This process mainly verifies the validity of the downloaded data, including its size, and ensures the data file's encryption type is correct, including decrypting the VBF (Vehicle Bulletin File) file.

[0235] Furthermore, if the vehicle information does not meet the preset verification items before the vehicle update, the OTA update task can be postponed. The unsatisfactory verification items will be output after the preset vehicle update pre-verification is completed.

[0236] Referring to Figure 10, which is a flowchart illustrating the sixth embodiment of this application based on the third, fourth, and fifth embodiments, the same or similar content as the above embodiments can be referred to the above description and will not be repeated hereafter. The step of determining the execution time for the vehicle to complete the OTA update task includes steps S11 to S12:

[0237] Step S11: Determine the local update duration required for each update unit in the vehicle corresponding to the OTA update task;

[0238] Step S12: Determine the execution time for the vehicle to complete the OTA update task based on the local update duration.

[0239] In this embodiment, the execution time of the OTA update task will be calculated by the vehicle.

[0240] For example, in practical applications, the cloud can send the partial update durations required for each update unit involved in this OTA update task to the vehicle, or the vehicle can determine the partial update durations for each update unit involved in this OTA update task based on a locally stored mapping table between update units and partial update durations. Depending on the vehicle's update method, different methods can be used to calculate the execution duration. For instance, if the vehicle's update method is serial, the execution duration can be obtained by summing the durations of each partial update. If the vehicle's update method is parallel, the longest partial update duration can be used as the execution duration, and so on.

[0241] In one embodiment, the step of determining the execution time for the vehicle to complete the OTA update task based on the duration of each local update includes steps S121 to S123:

[0242] Step S121: Based on the current vehicle usage scenario, determine the ignore update units in each update unit, wherein the ignore update units are update units whose usage probability is less than a preset threshold in the current usage scenario;

[0243] Step S122: Remove the local update duration of the ignored update unit from each of the local update durations to obtain the target local update duration set;

[0244] Step S123: Based on the longest local update duration in the target local update duration set, determine the execution time for the vehicle to complete the OTA update task.

[0245] In this embodiment, the update units that can ignore their update time will be further selected from each update unit, thereby further reducing the execution time.

[0246] For example, based on the vehicle's current usage scenario, ignore update units are determined among the update units. These ignore update units are those whose usage probability is less than a preset threshold in the current usage scenario. During the update process, the vehicle further determines the probability of each update unit being used in the current usage scenario. The probability of a new unit being used can be statistically obtained from the historical usage of each update unit in the current usage scenario; the specific statistical process is not detailed here. It is understandable that the corresponding functions of each update unit participating in the update are usually unusable during the update process. However, if the user will not use the function of a certain update unit in the current usage scenario (i.e., update units with a usage probability less than a preset threshold), the user will not perceive the unusability of that update unit's function (i.e., the update unit can be seamlessly rewritten or updated). Therefore, the partial update duration of that update unit can be ignored. For example, in a driving scenario, the user will rarely use the tailgate opening / closing function; therefore, the partial update duration of the update unit corresponding to the tailgate opening / closing function can be ignored. Correspondingly, the local update durations that ignore update units are removed from each local update duration, thus obtaining the target local update duration set.

[0247] The execution time of the OTA update task is then determined based on the target set of local update durations. Parallel updates are preferred, so the execution time of the OTA update task can be determined based on the longest local update duration in the target set of local update durations. It is worth noting that in practical applications, the number of channels for parallel updates is usually limited. Therefore, the steps described above for determining the execution time of the vehicle to complete the OTA update task based on the longest local update duration in the target set of local update durations may include:

[0248] If the number of update units is less than or equal to the preset parallel update channels, the longest local update duration in the target local update duration set can be directly used as the execution duration of the OTA update task. If the number of update units is greater than the preset parallel update channels, the longest local update duration in the target local update duration set is used as the base duration of this round of parallel updates. Based on the base duration, local update durations in the target local update duration set are allocated to each preset parallel update channel, wherein the total duration of local update durations allocated in each preset parallel update channel is less than or equal to the base duration. The local update durations already allocated to the preset parallel update channels are removed from the target local update durations to obtain a new target local update duration set. Based on the new target local update duration set, the step of using the longest local update duration in the target local update duration set as the base duration of this round of parallel updates is returned until the final target local update duration set is empty. The base duration of each round of parallel updates is accumulated to obtain the execution duration of the OTA update task.

[0249] This embodiment, given a limited number of preset parallel update channels, rationally plans the content of each round of parallel updates (i.e., the allocated local update duration for each round, representing the update unit to be updated in that round), thereby compressing the execution time of OTA update tasks as much as possible. This reduces the overall update cycle time and improves the user's driving experience.

[0250] This application also provides an OTA update device, as shown in FIG11, the OTA update device includes:

[0251] The determination module 10 is used to receive OTA update tasks and determine the execution time for the vehicle to complete the OTA update task;

[0252] Skip module 20 is used to skip the preset vehicle update pre-verification when the execution time is less than or equal to the verification time required to perform the preset vehicle update pre-verification.

[0253] Execution module 30 is used to execute the OTA update task.

[0254] In one embodiment, the OTA update device further includes a vehicle condition check module 40, which is used for:

[0255] Obtain the current vehicle status;

[0256] If the current vehicle status meets the preset vehicle conditions, the step of determining the execution time for the vehicle to complete the OTA update task is executed.

[0257] If the current vehicle status does not meet the preset vehicle conditions, a prompt message is output based on the target status information in the current vehicle status that does not meet the preset vehicle conditions.

[0258] In one embodiment, the OTA update device further includes a pre-verification module 50, the pre-verification module 50 being used for:

[0259] If the execution time is longer than the vehicle pre-verification time, the preset vehicle pre-update verification is performed.

[0260] After the preset vehicle update pre-verification is passed, the OTA update task is executed.

[0261] In one embodiment, the pre-verification module 50 is further configured to:

[0262] Obtain the vehicle information of the vehicle;

[0263] If the vehicle information meets the preset vehicle pre-update verification items, the preset vehicle pre-update verification is determined to be passed. The preset vehicle pre-update verification items include at least one of the following: the vehicle has obtained update authorization; the vehicle's identity identifier is the same as the task vehicle identifier of the OTA update task; there are no occupants in the vehicle; the vehicle's power supply is active; the vehicle's three-electric system has entered OTA status; the vehicle's anti-theft system is normal; the vehicle is locked; each update unit in the vehicle corresponding to the OTA update task is online; the preset update unit in each update unit has received the update file key; the vehicle's management module has entered OTA status; and the vehicle's fault codes have been cleared.

[0264] In one embodiment, the determining module 10 is further configured to:

[0265] Determine the local update duration required for each update unit in the vehicle corresponding to the OTA update task;

[0266] The execution time for the vehicle to complete the OTA update task is determined based on the duration of each local update.

[0267] In one embodiment, the determining module 10 is further configured to:

[0268] Based on the current vehicle usage scenario, the ignore update units in each update unit are determined, wherein the ignore update units are update units whose usage probability is less than a preset threshold in the current usage scenario;

[0269] The local update durations of the ignored update units are removed from each of the local update durations to obtain the target local update duration set;

[0270] Based on the longest local update duration in the target local update duration set, the execution time for the vehicle to complete the OTA update task is determined.

[0271] The OTA update device provided in this application, employing the OTA update method in the above embodiments, can solve the technical problem of long upgrade times in practical applications of related vehicle OTA upgrade technologies. Compared with the prior art, the beneficial effects of the OTA update device provided in this application are the same as those of the OTA update method provided in the above embodiments, and other technical features in the OTA update device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0272] In over-the-air (OTA) vehicle upgrade technologies, to avoid the risk of upgrade failure due to accidental human error during the upgrade process, a pre-verification is usually performed before the upgrade to ensure the vehicle can complete the update smoothly. It's important to note that pre-verification itself is not part of the actual upgrade step, and while it reduces the risk of upgrade failure, it inevitably increases the time required for the OTA upgrade.

[0273] The main solution of this application embodiment is: receiving an OTA update task and determining the vehicle's idle upgrade period for the OTA update task; when the vehicle is in the idle upgrade period, skipping the vehicle's pre-update verification and executing the OTA update task.

[0274] In other words, after receiving an OTA update task, the vehicle's idle upgrade period can be determined based on the user's scheduled actions. It's understandable that during idle periods, users are unlikely to perform any operations on the vehicle. Therefore, the risk of upgrade failure due to human error during idle periods is very small. Thus, this application skips the pre-update verification step and directly executes the OTA update task during idle periods. In summary, this application chooses to skip pre-update verification during idle upgrade periods. On the one hand, this reduces the overall OTA upgrade time; on the other hand, because it is skipped during idle upgrade periods, even with the pre-update verification skipped, the risk of upgrade failure is not significantly increased.

[0275] The execution subject of this embodiment can be a computing service device with data processing, network communication and program execution functions, such as a cloud platform, computer, mobile phone, etc., or a vehicle capable of performing the above functions.

[0276] Based on this, this application provides an OTA update method. Referring to FIG12, it is a flowchart of the seventh embodiment of the OTA update method of this application.

[0277] In this embodiment, the OTA update method includes steps S10 to S20:

[0278] Step S10: Receive OTA update task and determine the vehicle's idle upgrade period for the OTA update task;

[0279] In this embodiment, the above-described OTA update method can be applied to a vehicle or a cloud server associated with the vehicle. The OTA update task typically carries update data packages for each update unit in the vehicle, where an update unit refers to the ECU (Electronic Control Unit) that needs to be updated in the OTA update task. Furthermore, the OTA update task may also carry other information as needed, such as an update list that may include the required update duration for each update unit.

[0280] For example, a vehicle can receive OTA update tasks sent by a vehicle upgrade center (i.e., the cloud used to issue upgrade tasks to vehicles), and the process of receiving an OTA update task is the process of downloading the update data package. Correspondingly, after downloading the update data package, the vehicle's infotainment system can display an upgrade (update) prompt message, which may include options for "upgrade immediately" and "schedule an upgrade." If the user selects "upgrade immediately," the vehicle can begin preparing for the upgrade, such as performing pre-update verification (the user may be prompted to get out of the vehicle and wait for the upgrade before the pre-update verification). This pre-update verification refers to a self-check operation performed before the actual update to ensure the vehicle can complete the update (or upgrade) normally. For example, the pre-update verification may include checking whether anyone is in the vehicle, whether each update unit is online, and whether the vehicle is locked. The specific verification content can be set by technicians according to actual needs, and no specific restrictions are imposed here. Conversely, if the user does not want to upgrade at the moment, they can choose the option to schedule an upgrade and schedule a free time (a period when the vehicle is not in use) for the upgrade based on their driving habits. For example, the user's reservation operation described above could be a selection operation where the user chooses a time period (e.g., the selection operation could include the user choosing the start and end points of the selected time period). Correspondingly, the vehicle can respond to the user's reservation operation and determine its available upgrade time period. For instance, the vehicle's available upgrade time period could be the selected time period obtained from the aforementioned selection operation. Alternatively, the vehicle or cloud service can provide predicted available time periods for the user to choose from, and the selected available time period becomes the vehicle's available upgrade time period.

[0281] In addition, the user's reservation action can also be an agreement to the nighttime upgrade agreement, which is equivalent to the user defaulting to upgrading at night for each reservation. For example, the nighttime upgrade agreement can be preset to upgrade at a fixed time in the early morning (such as after 2 a.m.), and the fixed time in the early morning is the same as the above-mentioned vehicle idle time.

[0282] Step S20: If the vehicle is in an idle upgrade period, skip the vehicle's pre-update verification and execute the OTA update task.

[0283] For example, the aforementioned vehicle idle upgrade period is typically a future time period relative to when the vehicle will receive the OTA update task. Therefore, the vehicle needs to wait for a certain period before entering the vehicle idle upgrade period. During the vehicle idle upgrade period, if the vehicle is in a dormant state, it can be automatically woken up by a timer pre-set according to the vehicle idle upgrade period, or the cloud can wake the vehicle through the vehicle's TCAM (Telematics Control Unit) to perform the upgrade. It should be noted that the pre-update verification is mainly used to avoid the risk of upgrade failure caused by user operation during the upgrade process. Furthermore, since the vehicle idle upgrade period is a user-confirmed idle period, users generally will not perform any operations on the vehicle during this time. Consequently, there is no risk of upgrade failure caused by user operation during the upgrade process. Therefore, in this embodiment, if the current time period is within the vehicle idle upgrade period, the vehicle can skip the pre-update verification step and directly execute the OTA update task, which is the step of installing update data packages for each ECU. It is understandable that, in this embodiment, when the vehicle is in an idle upgrade period, the pre-update verification is skipped and the OTA update task is executed directly, thus reducing the time required for the entire vehicle OTA upgrade.

[0284] In this embodiment, an OTA update task is received, and the vehicle's idle upgrade period for the OTA update task is determined. If the vehicle is in an idle upgrade period, the pre-update verification is skipped, and the OTA update task is executed. That is, after receiving the OTA update task, the vehicle's idle upgrade period can be determined based on the user's scheduled actions. It is understood that during idle periods, users generally do not perform any operations on the vehicle. Therefore, the risk of upgrade failure due to human error during idle periods is very small. Thus, this application skips the pre-update verification step and directly executes the OTA update task when upgrading during idle periods. In summary, this application chooses to skip pre-update verification during vehicle idle upgrade periods. On the one hand, this reduces the overall OTA upgrade time; on the other hand, since it is skipped during idle periods, even if pre-update verification is skipped, it does not cause excessive risk of upgrade failure.

[0285] In one embodiment, the step of determining the vehicle's idle upgrade period for the OTA update task includes step S100:

[0286] Step S100: If the vehicle is in a custom appointment upgrade mode, receive the scheduled custom upgrade time period and use the custom upgrade time period as the vehicle's idle upgrade time period.

[0287] Users can customize the time slot for upgrading when the vehicle is in custom appointment upgrade mode. For example, in custom appointment upgrade mode, an upgrade date field can be displayed on the vehicle, allowing users to select the upgrade date. After selecting a date, the upgrade start time for that date is displayed, which users can select by swiping up or down. Based on the start time, users can generate an upgrade end time according to the required upgrade duration. The upgrade start and end times together constitute the vehicle's available upgrade time slots. The custom appointment operation involves the user selecting the upgrade date and the upgrade start time. It is understood that custom appointment upgrade mode allows users to freely choose available upgrade time slots, ensuring upgrade flexibility.

[0288] Referring to Figure 13, which is a schematic diagram of the interface corresponding to the custom appointment upgrade mode in this application, the interface includes areas for the user to select the upgrade date and for the user to select the upgrade start time. After the user selects the upgrade start time, the vehicle can automatically generate the upgrade end time based on the upgrade duration. Furthermore, the interface also includes automatic nighttime upgrades. When the user selects this option, the vehicle will automatically upgrade at a fixed time during the night for each subsequent upgrade.

[0289] In one embodiment, the OTA update method further includes steps S01 to S03:

[0290] Step S01: When the vehicle is in an idle upgrade period, obtain the current vehicle status;

[0291] Step S02: If the current vehicle status meets the preset vehicle conditions, then the step of skipping the pre-update verification of the vehicle is executed.

[0292] Step S03: If the current vehicle status does not meet the preset vehicle conditions, then output the abnormal vehicle status in the current vehicle status that does not meet the preset vehicle conditions.

[0293] To ensure the safety of the upgraded vehicle, this embodiment will also perform a preset vehicle condition check before the upgrade.

[0294] For example, after entering the aforementioned vehicle idle upgrade period, if the vehicle is in a dormant state, it will be woken up (since it is a scheduled upgrade, the vehicle is basically in a dormant state). After the vehicle is woken up, its current vehicle status is obtained, which may include the vehicle's gear position, speed, and power supply. The current vehicle status is then compared with preset vehicle conditions, which may include the vehicle being in Park (P) gear, speed at 0, and the vehicle not in motion. If the current vehicle status meets these preset conditions, the steps to skip the pre-update verification can be executed, allowing direct OTA update. Conversely, if the current vehicle status does not meet the preset conditions, an abnormal vehicle status is output. This can be displayed directly on the vehicle's infotainment screen or via a mobile device associated with the vehicle for the user's reference. It is understood that the preset vehicle conditions primarily consider the impact of the upgrade on the vehicle, avoiding potential safety risks.

[0295] Referring to Figure 14, which is a flowchart of the eighth embodiment of this application based on the seventh embodiment, the same or similar content as the above embodiments can be referred to the above description and will not be repeated hereafter. The step of determining the vehicle idle upgrade period of the OTA update task further includes steps S110 to S120:

[0296] Step S110: When the vehicle is in the recommended upgrade mode, predict the future idle time period of the vehicle to obtain candidate time periods and output the candidate time periods; Step S120: Use the selected candidate time period as the idle upgrade time period of the vehicle.

[0297] In this embodiment, the vehicle's mode type may also include a recommended upgrade mode. A recommended upgrade mode provides several predicted idle time periods for the user to choose from.

[0298] For example, in the recommended upgrade mode, the vehicle or a cloud server connected to the vehicle can predict the vehicle's future idle time slots based on the user's driving habits and obtain candidate time slots. The candidate time slots are then displayed on the vehicle's infotainment screen for the user to select. The user can choose a candidate time slot according to their own schedule, and the selected candidate time slot is the aforementioned vehicle idle upgrade time slot.

[0299] Providing users with several candidate time slots to choose from can significantly reduce the steps required for users to schedule upgrades, thereby improving the user experience. In practical applications, the recommended upgrade mode can be used by default to suggest several candidate time slots to users. If none of the recommended time slots match the user's needs, the user can choose to switch to the custom appointment upgrade mode to obtain a custom available upgrade time slot.

[0300] In one embodiment, the step of predicting the future idle time of the vehicle to obtain candidate time periods includes steps S111 to S113:

[0301] Step S111: Obtain time period characteristic data for a preset future time period;

[0302] Step S112: Input the time period feature data into a preset idle prediction model to obtain the vehicle's future idle time periods;

[0303] Step S113: Based on the upgrade duration of the OTA update task, candidate time periods are divided from the idle time periods.

[0304] In this embodiment, a preset idle prediction model will be used to predict future idle periods. This preset idle prediction model can be a neural network model, and it has been pre-trained to enable it to identify whether a future period will be idle or in use.

[0305] For example, time period characteristic data for a preset future time period is obtained. This future time period can be divided into sub-time periods within a future day, two days, three days, or week. The size of each sub-time period can be set by technicians according to actual needs; no specific restrictions are imposed here. In practical applications, there are usually multiple future time periods, and the processing procedure for each future time period is basically the same. Therefore, this embodiment will use one as an example for explanation. For any given future time period, time period characteristic data can be obtained. This time period characteristic data can include the time interval of the future time period, such as from 1:00 AM to 2:00 AM; it can include the weather conditions of the future time period, such as rain, snow, strong winds, sunny, or cloudy; and the weather conditions can also include the temperature, such as 20°C. Those skilled in the art can also set other time period characteristic data based on the above example. After obtaining the time period characteristic data, it is input into a preset idle prediction model. The preset idle prediction model can then classify the future time period according to the time period characteristic data, classifying it as idle or busy. If it is classified as idle, then this future time period is the vehicle's idle time period in the future.

[0306] In one embodiment, before the step of inputting the time period feature data into a preset idle prediction model to obtain the vehicle's future idle time periods, the method includes steps A10 to A20:

[0307] Step A10: Generate a target training sample set corresponding to the vehicle based on the vehicle's historical usage records;

[0308] Step A20: Fine-tune the initial pre-trained prediction model based on the training samples in the target training sample set to obtain the preset idle prediction model.

[0309] In this embodiment, the initial pre-trained prediction model is fine-tuned to obtain the aforementioned preset idle prediction model.

[0310] For example, a target training sample set corresponding to the vehicle can be generated based on the vehicle's historical usage records. The training samples in the target training sample set can include training samples from the vehicle's idle periods and training samples from its usage periods. The initial pre-trained prediction model is then fine-tuned using the target training sample set. It is worth noting that the initial pre-trained prediction model can be trained using training samples from a large number of vehicles. Therefore, the initial pre-trained prediction model is not specific to any particular vehicle, but it learns general usage patterns. Fine-tuning refers to retraining the initial pre-trained prediction model using the target training sample set for that vehicle. The training process mainly involves updating the model parameters in the initial pre-trained prediction model based on the difference between the prediction results of the initial pre-trained prediction model for the training samples and the labels of the training samples. Specifically, the model training algorithm can be selected by technical personnel according to actual needs, and will not be elaborated here. Furthermore, during the fine-tuning process, some model parameters in the initial pre-trained prediction model can be fixed. Fixing model parameters means that when updating the model parameters in the initial pre-trained prediction model using training samples from the target training sample set, the fixed model parameters remain unchanged. The initial pre-trained prediction model, fine-tuned using the target training sample set, is a pre-defined idle prediction model specifically designed for the aforementioned vehicles. This ensures that the pre-defined idle prediction model can accurately predict candidate idle time periods.

[0311] In one embodiment, the step of generating a target training sample set corresponding to the vehicle based on the vehicle's historical usage records includes steps A11 to A14:

[0312] Step A11: Divide the historical vehicle usage records into sample time periods, wherein each sample time period includes the historical vehicle usage time periods and the historical non-use time periods of the vehicle.

[0313] Step A12: For any one of the sample time periods, obtain the sample feature data of the sample time period, wherein the sample feature data includes at least one of the following: the time period interval of the sample time period, the weather conditions of the sample time period, the vehicle usage cost information corresponding to the sample time period, and the social event information of the sample time period.

[0314] Step A13: Generate training samples by labeling the sample feature data with the sample time period, wherein when the sample time period is a historical vehicle usage time period, the label of the sample feature data is the vehicle usage time period, and when the sample time period is a historical non-vehicle usage time period, the label of the sample feature data is the idle time period.

[0315] Step A14: Construct the target training sample set using training samples generated based on each sample time period.

[0316] For example, the aforementioned historical vehicle usage records may include the time period from each vehicle start-up to shutdown, i.e., historical vehicle usage periods, while periods not considered historical usage periods are historical non-use periods. It should be noted that before using each historical usage period and each historical non-use period as a sample period, the historical usage periods and each historical non-use period are first filtered. For example, periods shorter than a preset duration are discarded, and the remaining historical usage periods and the remaining historical non-use periods are then used as sample periods.

[0317] Since the subsequent processing procedures for each sample period are basically the same, this embodiment will use one sample period as an example for explanation. For example, for any sample period within a sample period, sample feature data for that sample period is obtained. This sample feature data includes at least one of the following: the time interval of the sample period, the weather conditions of the sample period, the vehicle usage cost information corresponding to the sample period, and the social event information of the sample period. For example, the vehicle usage cost information corresponding to the sample period could be the oil price or the charging price of the sample period; the social event information of the sample period could be a festival corresponding to the sample period, or other social events, such as a concert or sports event held in the vehicle's location. Examples will not be listed here. Preferably, the sample feature data includes the time interval of the sample period, the weather conditions of the sample period, the vehicle usage cost information corresponding to the sample period, and the social event information of the sample period. Furthermore, it is worth noting that if the sample feature data includes the time interval, weather conditions, vehicle usage cost information, and social event information... In the step of obtaining time-period feature data for a preset future time period, the time-period feature data may include the time interval of the future time period, the weather conditions of the future time period, the vehicle usage cost information of the future time period, and the social event information of the future time period. After obtaining the sample feature data of the sample time period, the sample feature data is labeled with labels to generate training samples. Specifically, if the sample time period is a historical vehicle usage period, the label labeled with the sample feature data can be "vehicle usage period"; if the sample time period is a historical unused vehicle usage period, the label labeled with the sample feature data is "idle period". The labeled data is used for supervised training of the initial pre-trained prediction model, i.e., the step of fine-tuning the initial pre-trained prediction model in the above embodiment.

[0318] Referring to Figure 15, which is a schematic diagram of the interface corresponding to the recommended upgrade mode in this application, as shown in Figure 15, three time periods can be displayed on the screen for users to select. Furthermore, in the recommended upgrade mode, users can also switch to the custom appointment upgrade mode via the "Enter Custom Appointment Upgrade Mode" button.

[0319] This application also provides an OTA update device, as shown in FIG16, the OTA update device includes:

[0320] The determination module 10 is used to receive OTA update tasks and determine the vehicle idle upgrade period of the OTA update task;

[0321] Skip module 20 is used to skip the pre-update verification of the vehicle and execute the OTA update task when the vehicle is in an idle upgrade period.

[0322] In one embodiment, the determining module 10 is further configured to:

[0323] When the vehicle is in the custom appointment upgrade mode, the custom upgrade time slot is received and the custom upgrade time slot is used as the vehicle's idle upgrade time slot.

[0324] In one embodiment, the determining module 10 is further configured to:

[0325] When the vehicle is in the recommended upgrade mode, predict the vehicle's future idle time periods to obtain candidate time periods, and output the candidate time periods;

[0326] The selected candidate time period will be used as the vehicle idle upgrade time period.

[0327] In one embodiment, the determining module 10 is further configured to:

[0328] Obtain time-period characteristic data for a preset future time period;

[0329] The time period feature data is input into a preset idle prediction model to obtain the vehicle's future idle time periods;

[0330] Candidate time periods are obtained from the idle time periods based on the upgrade duration of the OTA update task.

[0331] In one embodiment, the OTA update device further includes a training module 30, the training module 30 being used for:

[0332] Generate a target training sample set corresponding to the vehicle based on the vehicle's historical usage records;

[0333] The initial pre-trained prediction model is fine-tuned based on the training samples in the target training sample set to obtain the preset idle prediction model.

[0334] In one embodiment, the training module 30 is further configured to:

[0335] Based on the historical vehicle usage records, each sample time period is divided, wherein each sample time period includes the vehicle's historical usage time period and the vehicle's historical non-use time period;

[0336] For any one of the sample time periods, obtain the sample feature data of the sample time period, wherein the sample feature data includes at least one of the following: the time period interval of the sample time period, the weather conditions of the sample time period, the vehicle usage cost information corresponding to the sample time period, and the social event information of the sample time period.

[0337] Training samples are generated by labeling the sample feature data with the sample time period, wherein when the sample time period is a historical vehicle usage time period, the label of the sample feature data is the vehicle usage time period, and when the sample time period is a historical non-vehicle usage time period, the label of the sample feature data is the idle time period.

[0338] The target training sample set is constructed by using training samples generated based on each sample time period.

[0339] In one embodiment, the training module 30 is further configured to:

[0340] When the vehicle is in an idle upgrade period, obtain the current vehicle status;

[0341] If the current vehicle status meets the preset vehicle conditions, then the step of skipping the pre-update verification of the vehicle is executed;

[0342] If the current vehicle status does not meet the preset vehicle conditions, then the abnormal vehicle status that does not meet the preset vehicle conditions in the current vehicle status is output.

[0343] The OTA update device provided in this application, employing the OTA update method in the above embodiments, can solve the technical problem of long upgrade times caused by related vehicle OTA upgrade technologies in order to avoid the risk of upgrade failure. Compared with the prior art, the beneficial effects of the OTA update device provided in this application are the same as those of the OTA update method provided in the above embodiments, and other technical features in the OTA update device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0344] This application provides a vehicle, the vehicle including: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the OTA update method in Embodiment 1 above.

[0345] Referring now to Figure 17, a structural schematic diagram suitable for implementing the vehicle embodiments of this application is shown. The vehicle shown in Figure 17 is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0346] As shown in Figure 17, the vehicle may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage device 1003 into a random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for vehicle operation. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the I / O interface 1006: input devices 1007 including, for example, a touchscreen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. The communication device 1009 allows the vehicle to communicate wirelessly or wiredly with other devices to exchange data. Although vehicles with various systems are shown in the figures, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0347] According to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0348] The vehicle provided in this application, employing the OTA update method described in the above embodiments, can solve the technical problem of long upgrade times in practical applications of related vehicle OTA upgrade technologies. Compared with the prior art, the beneficial effects of the vehicle provided in this application are the same as those of the OTA update method provided in the above embodiments, and other technical features of the vehicle are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0349] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0350] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0351] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the OTA update method in the above embodiments.

[0352] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0353] The aforementioned computer-readable storage medium may be included in the vehicle or may exist independently and not installed in the vehicle.

[0354] The aforementioned computer-readable storage medium carries one or more programs that, when executed by a vehicle, cause the vehicle to:

[0355] After receiving an OTA update task, obtain the vehicle's current vehicle status;

[0356] When the current vehicle status meets the preset vehicle conditions, the vehicle is subjected to a pre-update verification. The preset vehicle conditions include modified conditions obtained by changing the verification conditions in the preset original pre-update verification. The pre-update verification is obtained by removing the verification conditions corresponding to the modified conditions in the preset original pre-update verification.

[0357] After the pre-update verification passes, the OTA update task is executed.

[0358] The aforementioned computer-readable storage medium carries one or more programs that, when executed by a vehicle, cause the vehicle to:

[0359] Receive OTA update task and determine the execution time for the vehicle to complete the OTA update task;

[0360] If the execution time is less than or equal to the verification time required to perform the preset vehicle update pre-verification, the preset vehicle update pre-verification is skipped.

[0361] Execute the OTA update task.

[0362] The aforementioned computer-readable storage medium carries one or more programs that, when executed by a vehicle, cause the vehicle to:

[0363] Receive OTA update tasks and determine the vehicle's idle upgrade period for the OTA update task;

[0364] If the vehicle is in an idle upgrade period, skip the vehicle's pre-update verification and execute the OTA update task.

[0365] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0366] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. Each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0367] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0368] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described OTA update method, which can solve the technical problem of long upgrade times in practical applications of related vehicle OTA upgrade technologies. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the OTA update method provided in the above embodiments, and will not be repeated here.

[0369] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the OTA update method described above.

[0370] The computer program product provided in this application can solve the technical problems of OTA updates. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as the beneficial effects of the OTA update method provided in the above embodiments, and will not be repeated here.

[0371] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. An OTA update method, wherein, The OTA update method includes the following steps: After receiving an OTA update task, obtain the vehicle's current vehicle status; When the current vehicle status meets the preset vehicle conditions, the vehicle is subjected to a pre-update verification. The preset vehicle conditions include modified conditions obtained by changing the verification conditions in the preset original pre-update verification. The pre-update verification is obtained by removing the verification conditions corresponding to the modified conditions in the preset original pre-update verification. After the pre-update verification passes, the OTA update task is executed.

2. The OTA update method as described in claim 1, wherein, After the step of obtaining the current vehicle status, the method further includes: If the current vehicle status does not meet the preset vehicle conditions, a prompt message is determined based on the target status information in the current vehicle status that does not meet the preset vehicle conditions. The prompt message is displayed on the vehicle's infotainment screen.

3. The OTA update method as described in claim 1, wherein, The steps for performing pre-update verification on the vehicle include: Obtain the vehicle information of the vehicle; If the vehicle information meets the verification conditions of the pre-update verification, the pre-update verification is determined to be passed. The verification conditions of the pre-update verification include at least one of the following: the vehicle has obtained update authorization; the vehicle's identity identifier is the same as the task vehicle identifier of the OTA update task; there are no occupants in the vehicle; the vehicle's power supply is active; the vehicle's three-electric system is in OTA state; the vehicle's anti-theft system is normal; the vehicle is in full vehicle lockout; each update unit in the vehicle corresponding to the OTA update task is online; the preset update unit in each update unit has received the update file key; the vehicle's management module is in OTA state; and the vehicle's fault codes have been cleared. Each update unit is an electronic control unit that controls the vehicle.

4. The OTA update method as described in claim 1, wherein, The steps for performing the OTA update task include: For any update unit in the OTA update task, determine the target update data corresponding to the update unit; The target update data is written to the data storage area of ​​the update unit, and the data stored in the data storage area is verified after the writing is completed; After the verification is passed, the update unit is updated.

5. The OTA update method as described in claim 4, wherein, After the step of determining the target update data corresponding to the update unit, the method includes: If the target update data fails to be written to the data storage area, or if the data stored in the data storage area fails to be verified, then the historical data in the data backup area corresponding to the update unit is used to overwrite the data stored in the data storage area, so as to roll back the system version of the update unit.

6. The OTA update method as described in claim 4, wherein, Before the step of writing the target update data to the data storage area of ​​the update unit, the method includes: The collaborative units associated with the update unit are determined based on a preset collaborative work unit mapping table; The unit functions of the update unit and the coordination unit are disabled, wherein the unit functions of the update unit are re-enabled after the update unit finishes updating and the coordination unit that needs to be updated finishes updating.

7. An OTA update device, wherein, The OTA update device includes: The acquisition module is used to obtain the current vehicle status after receiving an OTA update task; The verification module is used to perform a pre-update verification on the vehicle when the current vehicle status meets the preset vehicle conditions. The preset vehicle conditions include modified conditions obtained by changing the verification conditions in the preset original pre-update verification. The pre-update verification is obtained by removing the verification conditions corresponding to the modified conditions in the preset original pre-update verification. An execution module is used to execute the OTA update task after the pre-update verification passes.

8. An OTA update method, wherein, The OTA update method includes the following steps: Receive OTA update task and determine the execution time for the vehicle to complete the OTA update task; If the execution time is less than or equal to the verification time required to perform the preset vehicle update pre-verification, the preset vehicle update pre-verification is skipped. Execute the OTA update task.

9. The OTA update method as described in claim 8, wherein, After the step of receiving the OTA update task, the method includes: Obtain the current vehicle status; If the current vehicle status meets the preset vehicle conditions, the step of determining the execution time for the vehicle to complete the OTA update task is executed. If the current vehicle status does not meet the preset vehicle conditions, a prompt message is output based on the target status information in the current vehicle status that does not meet the preset vehicle conditions.

10. The OTA update method as described in claim 8, wherein, After the step of receiving the OTA update task, the method further includes: If the execution time is longer than the vehicle pre-verification time, the preset vehicle pre-update verification is performed. After the preset vehicle update pre-verification is passed, the OTA update task is executed.

11. The OTA update method as described in claim 10, wherein, The steps for performing the preset vehicle pre-update verification include: Obtain the vehicle information of the vehicle; If the vehicle information meets the preset vehicle pre-update verification items, the preset vehicle pre-update verification is determined to be passed. The preset vehicle pre-update verification items include at least one of the following: the vehicle has obtained update authorization; the vehicle's identity identifier is the same as the task vehicle identifier of the OTA update task; there are no occupants in the vehicle; the vehicle's power supply is active; the vehicle's three-electric system has entered OTA status; the vehicle's anti-theft system is normal; the vehicle is locked; each update unit in the vehicle corresponding to the OTA update task is online; the preset update unit in each update unit has received the update file key; the vehicle's management module has entered OTA status; and the vehicle's fault codes have been cleared.

12. The OTA update method as described in claim 8, wherein, The steps for determining the execution time for the vehicle to complete the OTA update task include: Determine the local update duration required for each update unit in the vehicle corresponding to the OTA update task; The execution time for the vehicle to complete the OTA update task is determined based on the duration of each local update.

13. The OTA update method as described in claim 12, wherein, The step of determining the execution time for the vehicle to complete the OTA update task based on the duration of each local update includes: Based on the current vehicle usage scenario, the ignore update units in each update unit are determined, wherein the ignore update units are update units whose usage probability is less than a preset threshold in the current usage scenario; The local update durations of the ignored update units are removed from each of the local update durations to obtain the target local update duration set; Based on the longest local update duration in the target local update duration set, the execution time for the vehicle to complete the OTA update task is determined.

14. An OTA update device, wherein, The OTA update device includes: The determination module is used to receive OTA update tasks and determine the execution time for the vehicle to complete the OTA update task; The skip module is used to skip the preset vehicle update pre-verification if the execution time is less than or equal to the verification time required to perform the preset vehicle update pre-verification. The execution module is used to execute the OTA update task.

15. An OTA update method, wherein, The OTA update method includes the following steps: Receive OTA update tasks and determine the vehicle's idle upgrade period for the OTA update task; If the vehicle is in an idle upgrade period, skip the vehicle's pre-update verification and execute the OTA update task.

16. The OTA update method as described in claim 15, wherein, The step of determining the vehicle's idle upgrade period for the OTA update task includes: When the vehicle is in the custom appointment upgrade mode, the custom upgrade time slot is received and the custom upgrade time slot is used as the vehicle's idle upgrade time slot.

17. The OTA update method as described in claim 15, wherein, The step of determining the vehicle's idle upgrade period for the OTA update task further includes: When the vehicle is in the recommended upgrade mode, predict the vehicle's future idle time periods to obtain candidate time periods, and output the candidate time periods; The selected candidate time period will be used as the vehicle idle upgrade time period.

18. The OTA update method as described in claim 17, wherein, The step of predicting the future idle time of the vehicle to obtain candidate time periods includes: Obtain time-period characteristic data for a preset future time period; The time period feature data is input into a preset idle prediction model to obtain the vehicle's future idle time periods; Candidate time periods are obtained from the idle time periods based on the upgrade duration of the OTA update task.

19. The OTA update method as described in claim 18, wherein, Before the step of inputting the time period feature data into a preset idle prediction model to obtain the vehicle's future idle time periods, the method includes: Generate a target training sample set corresponding to the vehicle based on the vehicle's historical usage records; The initial pre-trained prediction model is fine-tuned based on the training samples in the target training sample set to obtain the preset idle prediction model.

20. The OTA update method as described in claim 19, wherein, The step of generating a target training sample set corresponding to the vehicle based on the vehicle's historical usage records includes: Based on the historical vehicle usage records, each sample time period is divided, wherein each sample time period includes the vehicle's historical usage time period and the vehicle's historical non-use time period; For any one of the sample time periods, obtain the sample feature data of the sample time period, wherein the sample feature data includes at least one of the following: the time period interval of the sample time period, the weather conditions of the sample time period, the vehicle usage cost information corresponding to the sample time period, and the social event information of the sample time period. Training samples are generated by labeling the sample feature data with the sample time period, wherein when the sample time period is a historical vehicle usage time period, the label of the sample feature data is the vehicle usage time period, and when the sample time period is a historical non-vehicle usage time period, the label of the sample feature data is the idle time period. The target training sample set is constructed by using training samples generated based on each sample time period.

21. The OTA update method as described in claim 15, wherein, The OTA update method also includes: When the vehicle is in an idle upgrade period, obtain the current vehicle status; If the current vehicle status meets the preset vehicle conditions, then the step of skipping the pre-update verification of the vehicle is executed; If the current vehicle status does not meet the preset vehicle conditions, then the abnormal vehicle status that does not meet the preset vehicle conditions in the current vehicle status is output.

22. A vehicle, wherein, The vehicle includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the OTA update method as described in any one of claims 1 to 6, 8 to 13, and 15 to 21.

23. A storage medium, wherein, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the OTA update method as described in any one of claims 1 to 6, 8 to 13, and 15 to 21.

24. A computer program product, wherein, The computer program product includes a computer program that, when executed by a processor, implements the steps of the OTA update method as described in any one of claims 1 to 6, 8 to 13, and 15 to 21.

Images