OTA updating method, vehicle, storage medium and product

Abstract

The invention discloses an OTA updating method, a vehicle, a storage medium and a product, and relates to the technical field of OTA, and the method comprises the steps: after the vehicle receives an OTA updating task, the vehicle does not directly carry out pre-verification like a related vehicle OTA updating technology, but firstly determines the execution time length of executing the OTA updating task, and then carries out the OTA updating task according to the execution time length of the OTA updating task; according to the method and the device, the OTA updating task can be directly executed by skipping the verification before the preset vehicle is updated and comparing the verification duration with the verification duration required for executing the verification before the preset vehicle is updated, so that the duration of the whole updating period of the vehicle is shortened, and the purpose of improving the vehicle using experience of a user is achieved. The verification before the preset vehicle is updated can be skipped under the condition that the execution duration is smaller than or equal to the verification duration.

Description

Technical Field

[0001] The present application relates to the field of OTA (Over-the-Air Technology) technology, and in particular to an OTA update method, vehicle, storage medium and product. Background Art

[0002] OTA refers to the use of the Internet to remotely update system software. As OTA technology becomes more and more popular in new energy vehicles, each OEM is trying to optimize OTA performance and the time consumed by OTA. In the relevant vehicle OTA upgrade technology, in order to ensure that the vehicle can be upgraded normally, the vehicle is usually pre-verified. It should be noted that the pre-verification process also takes time, and the vehicle will enter the BOOT state during the pre-verification process (the user will not be able to use the vehicle normally in the BOOT state). For users, they will also regard the time spent on the pre-verification as the vehicle OTA upgrade cycle. Therefore, the above-mentioned related vehicle OTA upgrade technology will take a long time to upgrade in actual application, thereby affecting the user's vehicle experience.

[0003] The above contents are only used to assist in understanding the technical solution of the present application and do not constitute an admission that the above contents are prior art. Summary of the invention

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

[0005] To achieve the above object, the present application proposes an OTA update method, which includes the following steps:

[0006] Receiving an OTA update task, and determining an execution time for the vehicle to complete the OTA update task;

[0007] If the execution time is less than or equal to the verification time required to execute the preset vehicle pre-update verification, skipping the preset vehicle pre-update verification;

[0008] Execute the OTA update task.

[0009] Optionally, after the step of receiving the OTA update task, the method includes:

[0010] Obtaining a current vehicle state of the vehicle;

[0011] In the case where the current vehicle state satisfies the preset vehicle condition, executing the step of determining the execution time for the vehicle to complete the OTA update task;

[0012] In a case where the current vehicle state does not satisfy a preset vehicle condition, prompt information is output based on target state information in the current vehicle state that does not satisfy the preset vehicle condition.

[0013] Optionally, after the step of receiving the OTA update task, the method further includes:

[0014] In the case where the execution time is longer than the vehicle pre-verification time, executing the preset vehicle pre-update verification;

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

[0016] Optionally, the step of performing the preset vehicle pre-update verification includes:

[0017] Obtaining vehicle information of the vehicle;

[0018] When the vehicle information satisfies the verification items of the preset vehicle pre-update verification, it is determined that the preset vehicle pre-update verification has passed, wherein the verification items of the preset vehicle pre-update verification include at least one of: the vehicle has obtained update authorization, the identity of the vehicle is the same as the task vehicle identity of the OTA update task, there are no occupants in the vehicle, the power of the vehicle is active, the three-electric system of the vehicle enters the OTA state, the anti-theft system of the vehicle is normal, the vehicle is in the vehicle locked, each update unit corresponding to the OTA update task in the vehicle is online, the preset update unit among the update units has received the update file key, the management module of the vehicle enters the OTA state, and the fault code of the vehicle has been cleared.

[0019] Optionally, the step of determining the execution time for the vehicle to complete the OTA update task includes:

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

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

[0022] Optionally, the step of determining the execution time for the vehicle to complete the OTA update task based on each local update time includes:

[0023] Based on the current vehicle usage scenario of the vehicle, determining an ignored update unit among the update units, wherein the ignored update unit is an update unit whose usage probability in the current vehicle usage scenario is less than a preset threshold;

[0024] Eliminate the local update duration of the ignored update unit from each of the local update durations to obtain a target local update duration collection;

[0025] Based on the longest local update duration in the target local update duration collection, determine the execution duration for the vehicle to complete the OTA update task.

[0026] In addition, to achieve the above purpose, the present application also proposes an OTA update device, the OTA update device comprising:

[0027] A determination module, configured to receive an OTA update task and determine an execution time for the vehicle to complete the OTA update task;

[0028] A skipping module, configured to skip the preset vehicle pre-update verification if the execution time is less than or equal to the verification time required to execute the preset vehicle pre-update verification;

[0029] An execution module is used to execute the OTA update task.

[0030] In addition, to achieve the above-mentioned purpose, the present application also proposes a vehicle, which includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the OTA update method described above.

[0031] In addition, to achieve the above-mentioned purpose, the present application also proposes a storage medium, which 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, the steps of the OTA update method described above are implemented.

[0032] In addition, to achieve the above-mentioned purpose, the present application also provides a computer program product, wherein the computer program product includes a computer program, and when the computer program is executed by a processor, the steps of the OTA update method described above are implemented.

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

[0034] In the embodiment of the present application, after the vehicle receives the OTA update task, it will not directly perform the pre-verification like the above-mentioned related vehicle OTA upgrade technology, but first determine the execution time of the OTA update task, and compare it with the verification time required for executing the preset vehicle pre-update verification. If the execution time is less than or equal to the verification time, the preset vehicle pre-update verification can be skipped and the OTA update task can be directly executed. It can be understood that since the role of the preset vehicle pre-update verification is to ensure that the vehicle can be updated (upgraded) normally, and to avoid the problem of the entire update cycle being prolonged due to the failure of the vehicle update midway, therefore, in the case of a longer actual update time, a certain amount of extra time can be spent on the pre-verification, thereby reducing the risk of the entire update cycle being prolonged. However, if the verification time of the pre-verification is longer than the time required for the update, the pre-verification time must be longer than the time delayed by the failure of the update midway, therefore, the pre-verification operation performed at this time cannot obtain the benefit of reducing the entire update cycle, and the corresponding part of the pre-verification can be skipped, and the invalid operation can be discarded to reduce the duration of the entire update (upgrade) cycle of the vehicle, so as to achieve the purpose of improving the user's car experience. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0036] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0037] Figure 1 This is a flow chart of the first embodiment of the OTA update method of this application;

[0038] Figure 2 This is a flow chart of the second embodiment of the OTA update method of this application;

[0039] Figure 3 This is a flow chart of the third embodiment of the OTA update method of this application;

[0040] Figure 4 This is a flowchart of the fourth embodiment of the OTA update method of the present application;

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

[0042] Figure 6This is a schematic diagram of the device structure of the hardware operating environment involved in the OTA update method in the embodiment of the present application.

[0043] The purpose, features and advantages of this application will be further described in conjunction with the embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0044] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of the present application and are not used to limit the present application.

[0045] In order to better understand the technical solution of the present application, a detailed description will be given below in conjunction with the accompanying drawings and specific implementation methods.

[0046] OTA refers to the use of the Internet to remotely update system software. As OTA technology becomes more and more popular in new energy vehicles, each OEM is trying to optimize OTA performance and the time consumed by OTA. In the relevant vehicle OTA upgrade technology, in order to ensure that the vehicle can be upgraded normally, the vehicle is usually pre-verified. It should be noted that the pre-verification process also takes time, and the vehicle will enter the BOOT state during the pre-verification process (the user will not be able to use the vehicle normally in the BOOT state). For users, they will also use the time spent on the pre-verification as the time required for the vehicle OTA upgrade. Therefore, the above-mentioned related vehicle OTA upgrade technology will take a long time to upgrade in actual application, thereby affecting the user's vehicle experience.

[0047] The main solution of the embodiment of the present application 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.

[0048] That is, after the vehicle in the implementation of this application receives the OTA update task, it will not directly perform the pre-verification like the above-mentioned related vehicle OTA upgrade technology, but first determine the execution time of the OTA update task, and compare it with the verification time required for executing the preset vehicle pre-update verification. If the execution time is less than or equal to the verification time, the preset vehicle pre-update verification can be skipped and the OTA update task can be executed directly. It can be understood that since the role of the preset vehicle pre-update verification is to ensure that the vehicle can be updated (upgraded) normally and avoid the problem of the entire update cycle being prolonged due to the failure of the vehicle update midway, therefore, in the case of a longer actual update time, a certain amount of extra time can be spent on the pre-verification, thereby reducing the risk of the entire update cycle being prolonged. However, if the verification time of the pre-verification is longer than the time required for the update, the pre-verification time must be longer than the time delayed by the failure of the update midway. Therefore, the pre-verification operation performed at this time cannot obtain the benefit of reducing the entire update cycle. Accordingly, the pre-verification part can be skipped, and the invalid operation can be discarded to reduce the duration of the entire update (upgrade) cycle of the vehicle, so as to achieve the purpose of improving the user's car experience.

[0049] It should be noted that the execution subject of this embodiment can be a computing service device with data processing, network communication and program running functions, such as a cloud platform, a computer, a mobile phone, etc., or a vehicle that can realize the above functions.

[0050] Based on this, the embodiment of the present application provides an OTA update method, referring to Figure 1 , which is a flow chart of the first embodiment of the OTA update method of the present application.

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

[0052] Step S10, receiving an OTA update task, and determining the execution time for the vehicle to complete the OTA update task;

[0053] It should be noted that, in this embodiment, the above-mentioned OTA update method is usually applied to vehicles. The vehicle can receive the OTA update task sent from the cloud, that is, the cloud can send OTA update tasks to different vehicles. Among them, the OTA update task usually carries the update data packet of each update unit in the vehicle, and the update unit refers to the ECU (Electronic Control Uni) in the vehicle that needs to be updated in the OTA update task. In addition, other information can also be carried in the OTA update task according to actual needs, such as the update list includes the update duration required for each update unit (that is, the local update duration that appears in subsequent steps).

[0054] Exemplarily, the vehicle can receive an OTA update task sent by the cloud, and then determine the execution time of the OTA update task. In actual applications, the cloud can also first calculate the execution time of the OTA update task, and use the execution time as the information carried by the OTA update task. After the vehicle receives the OTA update task, it can directly obtain the execution time from the OTA update task. Alternatively, the cloud only uses the update time required by each update unit as the information carried by 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. For example, in the case of serial updates, the execution time can be calculated by accumulating the update times. If in the case of parallel updates, the execution time can be determined by the longest update time.

[0055] Step S20, when the execution time is less than or equal to the verification time required to perform the preset vehicle pre-update verification, skipping the preset vehicle pre-update verification;

[0056] It should be noted that the above-mentioned preset vehicle pre-update verification (also known as pre-update verification) refers to a self-check and verification operation before the formal update in order to ensure that the vehicle can complete the update (or upgrade) normally. For example, the verification content in the preset vehicle pre-update verification may include checking whether there is anyone in the vehicle, whether each update unit is online, and whether the vehicle is locked, etc., wherein the specific verification content can also be set by the technical staff according to actual needs, which will not be repeated here. The verification time required for the above-mentioned preset vehicle pre-update verification can be obtained through testing, that is, the time required for the vehicle to complete the preset vehicle pre-update verification multiple times can be counted, and then the average time can be used as the above-mentioned verification time.

[0057] For example, after determining the execution time of the OTA update task, the above 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 the vehicle OTA update and improving the user's vehicle usage experience.

[0058] Step S30, executing the OTA update task.

[0059] Exemplarily, after skipping the above-mentioned preset vehicle pre-update verification, the OTA update task can be executed directly. The process of executing the OTA update task may include: backing up the current system so that it can be restored to the original state when the update fails; system installation, decompressing the update file (the corresponding update file can be decrypted if necessary), and writing the new software code to the vehicle's ECU (electronic control unit) or other modules that need to be updated. In addition, after the installation is complete, installation verification (or post-verification) may be required. Among them, during the installation process and the post-verification process, the vehicle is in the BOOT state, 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 also be set by the technician according to actual needs, which will not be repeated here.

[0060] In this embodiment, after the vehicle receives the OTA update task, it will not directly perform the pre-verification like the above-mentioned related vehicle OTA upgrade technology, but first determine the execution time of the OTA update task, and compare it with the verification time required for executing the preset vehicle pre-update verification. If the execution time is less than or equal to the verification time, the preset vehicle pre-update verification can be skipped and the OTA update task can be directly executed. It can be understood that since the role of the preset vehicle pre-update verification is to ensure that the vehicle can be updated (upgraded) normally, and to avoid the problem of the entire update cycle being prolonged due to the failure of the vehicle update midway, therefore, in the case of a longer actual update time, a certain amount of extra time can be spent on the pre-verification, thereby reducing the risk of the entire update cycle being prolonged. However, if the verification time of the pre-verification is longer than the time required for the update, the pre-verification time must be longer than the time delayed by the failure of the update midway, therefore, the pre-verification operation performed at this time cannot obtain the benefit of reducing the entire update cycle, and the corresponding part of the pre-verification can be skipped, and the invalid operation can be discarded to reduce the duration of the entire update (upgrade) cycle of the vehicle, thereby improving the user's car experience.

[0061] Reference Figure 2 , is a flow chart of the second embodiment of the present application proposed based on the first embodiment of the present application. For the same or similar contents as the above embodiment in this embodiment, please refer to the above introduction and will not be repeated later. After the step of receiving the OTA update task, the method includes steps S01 to S03:

[0062] Step S01, obtaining the current vehicle state of the vehicle;

[0063] Step S02, when the current vehicle state satisfies the preset vehicle condition, executing the step of determining the execution time for the vehicle to complete the OTA update task;

[0064] Step S03: when the current vehicle state does not satisfy the preset vehicle condition, output prompt information based on the target state information in the current vehicle state that does not satisfy the preset vehicle condition.

[0065] It should be noted that in this embodiment, before the vehicle is officially updated, a vehicle condition check will also be performed to ensure that the vehicle can complete the update normally (or safely). Among them, during the vehicle condition check process, the vehicle will not enter the BOOT state, so the vehicle can be used normally by the user during the vehicle condition check stage. It is worth noting that the whole vehicle has not entered the BOOT state during the condition check, and the whole vehicle signal interaction is interacted through application messages at this time. When the whole vehicle enters the BOOT state, the FOTA Master (firmware air upgrade master) in the vehicle completes the pre-verification, update and post-verification content. However, the FOTA Master running in the BOOT state cannot collect application message signals. The FOTA Master mainly receives diagnostic messages, such as DOIP (Diagnostic over Internet Protocol, based on Internet Protocol Diagnosis) messages. Correspondingly, before the vehicle is updated, it is necessary to divide the vehicle condition check and pre-verification process. And since the normal use of the vehicle by the user will not be affected during the vehicle condition check stage, the time spent in the vehicle condition check stage will not be included in the entire update cycle for the user.

[0066] Exemplarily, after the vehicle receives the OTA update task, the vehicle condition check may be performed first, including obtaining the current vehicle state of the vehicle. Among them, the specific vehicle state may be determined by the vehicle condition that needs to be checked, and the current vehicle state is interacted in the vehicle through application messages. The obtained current vehicle state is compared with the preset vehicle condition. If the current vehicle state meets the preset vehicle condition, it can be determined that the vehicle condition check has passed, otherwise, the vehicle condition check has not passed. Among them, the above-mentioned preset vehicle condition includes the change condition obtained by changing the check item (that is, the check condition) in the preset original pre-check, and the preset vehicle pre-update check is determined by removing the preset original pre-check corresponding to the check item of the change condition. That is, in this embodiment, some of the check items in the preset original pre-check are changed into the conditions in the preset vehicle conditions (that is, the above-mentioned change conditions). In addition, the preset original pre-check with the check items corresponding to the change conditions removed can also be directly used as the above-mentioned preset vehicle pre-update check. The above-mentioned change conditions may be that the vehicle power is greater than the preset power, the network working state is normal, etc. (the vehicle power is greater than the preset power and the network working state is normal, which were originally the check items in the preset original pre-check). In addition to the change conditions, the preset vehicle conditions may also include conditions such as the vehicle speed is less than the preset speed, the vehicle is in the parking gear, and the scene mode is turned off.

[0067] Exemplarily, if the preset vehicle condition includes that the vehicle is less than a preset speed, the current vehicle state obtained includes the vehicle's driving speed; if the preset vehicle condition includes that the vehicle is in a parking gear, the current vehicle state obtained includes the vehicle's gear information. That is, the current vehicle state obtained can be determined by the preset vehicle condition, so the specific vehicle state will not be repeated here. In addition, it should be noted that in this embodiment, part of the content placed in the pre-verification in the relevant vehicle OTA upgrade technology is transferred to the vehicle condition inspection process, such as the vehicle's power is greater than the preset power and the network working status is normal, so as to reduce the content of the pre-verification as much as possible, that is, reduce the verification time of the pre-verification, and shorten the entire update cycle when performing the pre-verification.

[0068] Exemplarily, when the current vehicle state does not meet the preset vehicle condition, a prompt message may be output based on the target state information in the current vehicle state that does not meet the preset vehicle condition. For example, if the vehicle's battery level is less than or equal to the preset battery level, the target state information may be the vehicle's battery level, and accordingly, the output prompt message is that the vehicle's battery level is too low and does not meet the condition that the vehicle's battery level is greater than the preset battery level, so that the user can charge the vehicle according to the prompt message. It is understandable that the form of the specific prompt message can be set by the technician according to actual needs and is related to the target state information, and will not be elaborated here.

[0069] In a feasible implementation manner, the step of outputting prompt information based on the target state information in the current vehicle state that does not meet the preset vehicle condition includes step S003:

[0070] Step S003, for any target state information in the current vehicle state that does not meet the preset vehicle condition, after determining the target state information, generate prompt information in real time according to the target state information, and output the prompt information through the vehicle computer screen.

[0071] For example, since the process of generating prompt information based on each target state information is roughly similar, one target state information will be used as an example for explanation in this embodiment. For example, for any target state information in the current vehicle state that does not meet the preset vehicle condition, after the vehicle inspection determines that the target state information is obtained, prompt information is generated in real time according to the target state information, and the prompt information is output to the user through the vehicle's on-board computer, so that the user can handle it in time.

[0072] It should be noted that part of the content placed in the pre-verification in the relevant vehicle OTA upgrade technology is transferred to the vehicle condition inspection process. In addition to reducing the verification time of the pre-verification, the vehicle can also be adjusted to meet the preset vehicle conditions in time. For example, since the pre-verification will enter BOOT, the vehicle's computer is in a black screen state at this time and cannot output information. Therefore, when a problem occurs during the verification, the user does not know what the cause is. He can only wait for the pre-verification process to be completed and check the problem on the mobile phone APP (Application), which affects the user experience and does not allow the user to deal with the problem in time. However, if part of the content in the pre-verification process is changed to the vehicle condition inspection part and a problem occurs, the problem (that is, the unsatisfactory preset vehicle condition) can be directly displayed on the large screen, and the user can know the reasons that affect the OTA upgrade in time, so as to deal with it in time.

[0073] Reference Figure 3 , is a flowchart of the third embodiment of the present application proposed based on the first embodiment and the second embodiment of the present application. For the same or similar contents as the above embodiments in this embodiment, please refer to the above introduction and will not be repeated later. After the step of receiving the OTA update task, the method further includes steps S40 to S50:

[0074] Step S40, when the execution time is longer than the vehicle pre-verification time, executing the preset vehicle pre-update verification;

[0075] Step S50, after the preset vehicle pre-update verification passes, executing the OTA update task.

[0076] Exemplarily, when the execution time of the preset vehicle pre-update verification is longer than the vehicle pre-verification time, the normal preset vehicle pre-update verification step can be performed. It can be understood that, according to the above content, the preset vehicle pre-update verification is used to avoid the problem of the entire update cycle being prolonged due to the failure of the vehicle update midway. Correspondingly, when the execution time of the OTA update task is long, that is, the update cycle is relatively long, if the update fails midway, the time wasted due to the failure midway may be much greater than the time occupied by the pre-verification. For example, if the vehicle OTA upgrade content is more and it takes 10 minutes, in actual application, if the vehicle OTA upgrade has a problem at the 9-minute stage and needs to be re-upgraded, it is equivalent to the 9 minutes spent before being wasted at this time, and the pre-verification takes 2 minutes, and the pre-verification can ensure that the vehicle can be updated normally. After adding the pre-verification step, it is equivalent to spending 2 minutes to avoid 9 minutes being wasted. On the contrary, if the vehicle OTA upgrade content is less and only takes 1 minute, even if there is a problem and fails at the 1-minute stage of the upgrade, it is still less than the time cost of performing a 2-minute verification. Correspondingly, after the previous verification is passed, the OTA update task can be executed.

[0077] In a feasible implementation manner, the step of performing the preset vehicle pre-update verification includes steps S41 to S42:

[0078] Step S41, obtaining vehicle information of the vehicle;

[0079] Step S42, when the vehicle information satisfies the verification items of the preset vehicle pre-update verification, it is determined that the preset vehicle pre-update verification has passed, wherein the verification items of the preset vehicle pre-update verification include at least one of the following: the vehicle has obtained update authorization, the identity of the vehicle is the same as the task vehicle identity of the OTA update task, there are no occupants in the vehicle, the power of the vehicle is active, the three-electric system of the vehicle enters the OTA state, the anti-theft system of the vehicle is normal, the vehicle is in the whole vehicle locked, each update unit in the vehicle corresponding to the OTA update task is online, the preset update unit in each of the update units has received the update file key, the management module of the vehicle enters the OTA state, and the fault code of the vehicle has been cleared.

[0080] Exemplarily, the steps of performing the preset vehicle pre-update verification in this embodiment include that 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-verification. When the verification items include that there are no occupants in the vehicle, the vehicle information may include the number of occupants in the vehicle. When the verification items include that the vehicle's identity is the same as the task vehicle identity of the OTA update task, the vehicle information may include the vehicle's identity, etc., which will not be elaborated here.

[0081] The acquired vehicle information is compared with the verification items of the preset vehicle pre-update verification. If the vehicle information meets the verification items of the preset vehicle pre-update verification, it can be determined that the preset vehicle pre-update verification has passed. Among them, the verification items at least include that the vehicle has obtained update authorization, the vehicle's identity is the same as the task vehicle identity of the OTA update task, there are no passengers in the vehicle, the vehicle's power supply is active, the vehicle's three-electric system enters the OTA state, the vehicle's anti-theft system is normal, the vehicle is in the vehicle lock, the update units corresponding to the OTA update task in the vehicle are online, the preset update units in each update unit have received the update file key, the vehicle's management module enters the OTA state, and the vehicle's fault code has been cleared. At least one of the following. It should be noted that the verification items can be freely combined by technicians according to the above conditions. In order to avoid risks, it is preferred that the verification items include the above conditions.

[0082] Furthermore, the verification item is that the vehicle has obtained the update authorization. The corresponding verification process is that the vehicle outputs the option of whether to update through the HMI ("Human-Machine Interface", human-machine interaction interface), and accordingly, the update authorization is obtained after the user chooses to agree to the update. It is worth noting that in actual applications, when the user clicks on the upgrade installation, a regret period is set. During the regret period, the user can unlock the vehicle and drive the vehicle. At this time, the OTA upgrade task will not be carried out, and it will enter a postponed state, waiting for the next user to confirm the upgrade installation.

[0083] The identity of the verification item vehicle is the same as the task vehicle identifier of the OTA update task. The corresponding verification process is to check whether the UUID (Universally Unique Identifier) ​​on the vehicle side, that is, the vehicle identity, is the same as the UUID on the cloud side, that is, the task vehicle identifier. If they are inconsistent, it means that the task is invalid and needs to be reported as failure.

[0084] Verification item: There are no passengers in the vehicle. The corresponding verification process is life detection. This process is to prevent people from being in the car during the OTA upgrade. If there are people, the vehicle horn will sound. Because in actual applications, it is not recommended to have people in the car during the OTA upgrade. If people perform some unforbidden operations (i.e. high-authority operations, such as braking) in the car, the vehicle upgrade may fail. This verification item can be set according to the functional conditions of different projects and different models (some models may be configured with life detection).

[0085] The verification item is that the power of the vehicle is in an active state. The corresponding verification process is to check the power mode. This process is to check the power mode of the vehicle. After the regret time is over, the power mode of the vehicle must be inactive (active state). If the power mode is not met, the OTA update task is postponed.

[0086] The verification item is that the vehicle's three-electric system enters the OTA state. The corresponding verification process is to execute the power system to enter the OTA state. This process is that the FOTA Master sends diagnostic instructions to the domain control of the three-electric system to let the three-electric system enter the OTA state. Among them, the "three-electric system" usually refers to the three main electrical systems of electric vehicles: battery management system (BMS, Battery Management System), motor control system (MCU, Microcontroller Unit) and vehicle control unit (VCU, Vehicle Control Unit). When these systems enter the OTA state, it means that the vehicle is receiving or preparing to receive remote software updates from the manufacturer.

[0087] The verification item is that the anti-theft system of the vehicle is normal. The corresponding verification process is to check whether the anti-theft system is normal. This process is that FOTA Master sends diagnostic instructions to the domain control of the vehicle body to check the anti-theft status of the entire vehicle.

[0088] The verification item is that the vehicle is in the locked state. The corresponding verification process is to check whether the whole vehicle is locked. This process is that FOTAMaster sends a diagnostic command to the domain control of the vehicle body to check whether the lock status of the whole vehicle is locked.

[0089] The verification item is that each update unit corresponding to the OTA update task in the vehicle is in an online state. The corresponding verification process is to check the online state of the vehicle ECU. This process is that the FOTA Master sends a diagnostic command to the vehicle ECU to confirm the state of the vehicle ECU. If the ECU that is not in this OTA task (that is, it is not an update unit, and the ECU in this OTA task is the update unit) is not online, it will not affect this task, and the OTA upgrade task can be carried out normally.

[0090] 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 (that is, the preset update unit) for this OTA task. If the current OTA is assigned a distributed ECU, the file key of the distributed ECU is requested, and then the key is sent to the distributed ECU.

[0091] The verification item is that the management module of the vehicle enters the OTA state and the fault code of the vehicle has been cleared. The corresponding verification process is to clear the DTC (Diagnostic Trouble Code) preparation, which is to record and clear the existing DTC of the vehicle.

[0092] In addition to the above, the verification items for the preset vehicle pre-update verification may also include checking OTA pre-sales / after-sales. This process is to check the status of the vehicle, which is divided into pre-sales vehicles and after-sales vehicles. If the vehicle status is a pre-sales vehicle, it is not necessary to meet the verification item that the vehicle's identity identification is the same as the task vehicle identification of the OTA update task; check whether the network connection is online. This process mainly checks whether the vehicle's network status is normal. If the network status is not good or the network is disconnected, the OTA task cannot be performed and enters the postponement; check the battery pack power, that is, the large battery power. This process is to ensure that the battery pack power of the entire vehicle is not too low, because power is also consumed when performing OTA upgrades, to prevent the vehicle itself from performing OTA when the battery power is low, which has certain hidden dangers for users' subsequent use of the vehicle.

[0093] It is worth noting that the above-mentioned preset vehicle pre-update verification is a pre-verification that can be skipped if certain conditions are met. In addition, in this embodiment, a non-skippable vehicle pre-update verification can also be set, that is, data file verification. This process mainly verifies whether the downloaded data is valid, including the size of the downloaded data, and whether the encryption type of the data file meets the requirements, and the VBF (Vehicle Bulletin File) file will be decrypted.

[0094] In addition, if the vehicle information does not meet the verification items of the preset vehicle pre-update verification, the OTA update task can be postponed, and the unsatisfied verification items are output after the preset vehicle pre-update verification is completed.

[0095] Reference Figure 4 , is a flowchart of the fourth embodiment of the present application proposed based on the first embodiment, the second embodiment, and the third embodiment of the present application. In this embodiment, the same or similar contents as the above embodiments can be referred to the above introduction, and will not be repeated later. The step of determining the execution time of the vehicle to complete the OTA update task includes steps S11 to S12:

[0096] Step S11, determining the local update duration required for updating each update unit corresponding to the OTA update task in the vehicle;

[0097] Step S12, determining the execution time for the vehicle to complete the OTA update task based on the duration of each local update.

[0098] It should be noted that, in this embodiment, the execution duration of the OTA update task will be calculated by the vehicle.

[0099] For example, in actual applications, the cloud can send the local update duration required for updating each update unit involved in this OTA update task to the vehicle, or the vehicle determines the local update duration of each update unit involved in this OTA update task based on a mapping relationship table between update units and local update durations stored locally. Depending on the vehicle update method, different methods can be used to calculate the execution duration. For example, if the vehicle update method is serial update, the execution duration can be obtained by adding up the local update durations. If the vehicle update method is parallel update, the longest local update duration among the local update durations can be used as the execution duration, etc.

[0100] In a feasible implementation manner, the step of determining the execution time for the vehicle to complete the OTA update task based on each local update time includes steps S121 to S123:

[0101] Step S121, based on the current vehicle usage scenario of the vehicle, determining the ignored update unit among the update units, wherein the ignored update unit is an update unit whose usage probability in the current vehicle usage scenario is less than a preset threshold;

[0102] Step S122, removing the local update duration of the ignored update unit from each of the local update durations to obtain a target local update duration collection;

[0103] Step S123, based on the longest local update duration in the target local update duration collection, determine the execution duration for the vehicle to complete the OTA update task.

[0104] It should be noted that, in this embodiment, the update units whose update durations can be ignored are further screened out from the update units, thereby further compressing the execution duration.

[0105] Exemplarily, based on the current vehicle usage scenario of the vehicle, the ignored update unit in each update unit is determined, wherein the ignored update unit is an update unit whose usage probability in the current vehicle usage scenario is less than a preset threshold. During the update process, the vehicle will further determine the probability of each update unit being used in the current vehicle usage scenario, and the probability of the new unit being used can be obtained based on the historical usage statistics of each update unit in the current vehicle usage scenario. The specific statistical process is not repeated here. It can be understood that the corresponding functions of each update unit involved in the update are usually unusable during the update process, but if in the current vehicle usage scenario, the user himself will not use the function of a certain update unit (that is, the update unit with a usage probability less than a preset threshold), so the user will not perceive that the function of the update unit cannot be used (that is, the update unit can be written or updated without feeling), so the local update duration of the update unit can be ignored. For example, in the scenario of vehicle driving, the user basically does not use the switch function of the vehicle tailgate, so the local update duration of the update unit corresponding to the switch function of the vehicle tailgate can be ignored. Correspondingly, the local update durations of the ignored update units are removed from the local update durations, thereby obtaining a target local update duration collection.

[0106] Then, the execution duration of the OTA update task is determined based on the target local update duration collection. It is preferred to update in parallel, so the execution duration of the OTA update task can be determined based on the longest local update duration in the target local update duration collection. It is worth noting that in actual applications, the channels for parallel updates are usually limited. Therefore, the above-mentioned step of determining the execution duration of the vehicle to complete the OTA update task based on the longest local update duration in the target local update duration collection may include:

[0107] When 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 collection 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 collection is used as the basic duration for this round of parallel updates, and the local update duration in the target local update duration collection is allocated to each preset parallel update channel based on the basic duration, wherein the total duration of the allocated local update duration in each preset parallel update channel is less than or equal to the basic duration; the local update duration that has been allocated to the preset parallel update channel is eliminated from the target local update duration to obtain a new target local update duration collection; based on the new target local update duration collection, the step of using the longest local update duration in the target local update duration collection as the basic duration for this round of parallel updates is returned until the final target local update duration collection is empty, and the basic duration of each round of parallel updates is accumulated to obtain the execution duration of the OTA update task.

[0108] It is understandable that, in the case of limited preset parallel update channels, this embodiment reasonably plans the content of each round of parallel updates (i.e., the local update duration allocated for each round, which represents the update unit updated in this round), thereby compressing the execution time of the OTA update task as much as possible, reducing the duration of the entire update cycle and improving the user's car experience.

[0109] This application also provides an OTA update device, referring to Figure 5 , the OTA update device comprises:

[0110] A determination module 10 is used to receive an OTA update task and determine the execution time for the vehicle to complete the OTA update task;

[0111] A skipping module 20, configured to skip the preset vehicle pre-update verification if the execution time is less than or equal to the verification time required to execute the preset vehicle pre-update verification;

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

[0113] Optionally, the OTA update device further includes a vehicle condition checking module 40, and the vehicle condition checking module 40 is used to:

[0114] Obtaining a current vehicle state of the vehicle;

[0115] In the case where the current vehicle state satisfies the preset vehicle condition, executing the step of determining the execution time for the vehicle to complete the OTA update task;

[0116] In a case where the current vehicle state does not satisfy a preset vehicle condition, prompt information is output based on target state information in the current vehicle state that does not satisfy the preset vehicle condition.

[0117] Optionally, the OTA update device further includes a pre-verification module 50, and the pre-verification module 50 is used to:

[0118] In the case where the execution time is longer than the vehicle pre-verification time, executing the preset vehicle pre-update verification;

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

[0120] Optionally, the pre-verification module 50 is further used for:

[0121] Obtaining vehicle information of the vehicle;

[0122] When the vehicle information satisfies the verification items of the preset vehicle pre-update verification, it is determined that the preset vehicle pre-update verification has passed, wherein the verification items of the preset vehicle pre-update verification include at least one of: the vehicle has obtained update authorization, the identity of the vehicle is the same as the task vehicle identity of the OTA update task, there are no occupants in the vehicle, the power of the vehicle is active, the three-electric system of the vehicle enters the OTA state, the anti-theft system of the vehicle is normal, the vehicle is in the vehicle locked, each update unit corresponding to the OTA update task in the vehicle is online, the preset update unit among the update units has received the update file key, the management module of the vehicle enters the OTA state, and the fault code of the vehicle has been cleared.

[0123] Optionally, the determining module 10 is further configured to:

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

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

[0126] Optionally, the determining module 10 is further configured to:

[0127] Based on the current vehicle usage scenario of the vehicle, determining an ignored update unit among the update units, wherein the ignored update unit is an update unit whose usage probability in the current vehicle usage scenario is less than a preset threshold;

[0128] Eliminate the local update duration of the ignored update unit from each of the local update durations to obtain a target local update duration collection;

[0129] Based on the longest local update duration in the target local update duration collection, determine the execution duration for the vehicle to complete the OTA update task.

[0130] The OTA update device provided by this application adopts the OTA update method in the above embodiment, which can solve the technical problem that the relevant vehicle OTA update technology has a long upgrade time in actual application. Compared with the prior art, the beneficial effects of the OTA update device provided by this application are the same as the beneficial effects of the OTA update method provided by the above embodiment, and the other technical features in the OTA update device are the same as the features disclosed in the above embodiment method, which will not be repeated here.

[0131] The present application provides a vehicle, comprising: 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, and the instructions are executed by the at least one processor so that the at least one processor can execute the OTA update method in the above-mentioned embodiment one.

[0132] Reference below Figure 6 , which shows a schematic structural diagram of a vehicle suitable for implementing an embodiment of the present application. Figure 6 The vehicle shown is merely an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0133] like Figure 6 As shown, the vehicle may include a processing device 1001 (e.g., a central processing unit, a graphics processor, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM: Read Only Memory) 1002 or a program loaded from a storage device 1003 to a random access memory (RAM: Random Access Memory) 1004. In RAM1004, various programs and data required for vehicle operation are also stored. The processing device 1001, ROM1002, and RAM1004 are connected to each other via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Generally, the following systems can be connected to the I / O interface 1006: an input device 1007 including, for example, a touch screen, a touch pad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, etc.; an output device 1008 including, for example, a liquid crystal display (LCD: Liquid Crystal Display), a speaker, a vibrator, etc.; a storage device 1003 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 1009. The communication device 1009 can allow the vehicle to communicate with other devices wirelessly or by wire to exchange data. Although the figure shows a vehicle with various systems, it should be understood that it is not required to implement or have all the systems shown. More or fewer systems can be implemented or have alternatively.

[0134] In particular, according to the embodiments disclosed in the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, the embodiments disclosed in the present application include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication device, or installed from a storage device 1003, or installed from a ROM 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the method of the embodiment disclosed in the present application are executed.

[0135] The vehicle provided by this application adopts the OTA update method in the above embodiment, which can solve the technical problem that the relevant vehicle OTA upgrade technology has a long upgrade time in actual application. Compared with the prior art, the beneficial effects of the vehicle provided by this application are the same as the beneficial effects of the OTA update method provided by the above embodiment, and the other technical features in the vehicle are the same as the features disclosed in the method of the previous embodiment, which will not be repeated here.

[0136] It should be understood that the various parts disclosed in this application can be implemented by 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 one or more embodiments or examples in a suitable manner.

[0137] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

[0138] The present application provides a computer-readable storage medium having computer-readable program instructions (ie, computer programs) stored thereon, and the computer-readable program instructions are used to execute the OTA update method in the above-mentioned embodiment.

[0139] The computer-readable storage medium provided in the present application may be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, systems or devices, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. 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 combination with an instruction execution system, system or device. The program code contained on the computer-readable storage medium may be transmitted using any appropriate medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination of the above.

[0140] The computer-readable storage medium may be included in the vehicle, or may exist independently without being installed in the vehicle.

[0141] The computer-readable storage medium carries one or more programs. When the one or more programs are executed by a vehicle, the vehicle:

[0142] Receiving an OTA update task, and determining an execution time for the vehicle to complete the OTA update task;

[0143] If the execution time is less than or equal to the verification time required to execute the preset vehicle pre-update verification, skipping the preset vehicle pre-update verification;

[0144] Execute the OTA update task.

[0145] Computer program code for performing the operations of the present application may be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0146] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present application. In this regard, each square box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two square boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0147] The modules involved in the embodiments described in this application may be implemented by software or hardware, wherein the name of the module does not constitute a limitation on the unit itself in some cases.

[0148] The readable storage medium provided in this application is a computer-readable storage medium, which stores computer-readable program instructions (i.e., computer programs) for executing the above-mentioned OTA update method, and can solve the technical problem that the relevant vehicle OTA upgrade technology has a long upgrade time in practical applications. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as the beneficial effects of the OTA update method provided in the above-mentioned embodiment, and will not be repeated here.

[0149] The present application also provides a computer program product, including a computer program, which implements the steps of the above-mentioned OTA update method when executed by a processor.

[0150] The computer program product provided by this application can solve the technical problem of OTA update. Compared with the prior art, the beneficial effects of the computer program product provided by this application are the same as the beneficial effects of the OTA update method provided by the above embodiment, which will not be repeated here.

[0151] The above descriptions are only some embodiments of the present application, and are not intended to limit the patent scope of the present application. All equivalent structural changes made using the contents of the present application specification and drawings under the technical concept of the present application, or direct / indirect applications in other related technical fields are included in the patent protection scope of the present application.

Claims

1. An OTA update method, characterized in that: The OTA update method comprises the following steps: Receiving an OTA update task, and determining an 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 execute the preset vehicle pre-update verification, skipping the preset vehicle pre-update verification; Execute the OTA update task.

2. The OTA update method according to claim 1, characterized in that: After the step of receiving the OTA update task, the method includes: Obtaining a current vehicle state of the vehicle; In the case where the current vehicle state satisfies the preset vehicle condition, executing the step of determining the execution time for the vehicle to complete the OTA update task; In a case where the current vehicle state does not satisfy a preset vehicle condition, prompt information is output based on target state information in the current vehicle state that does not satisfy the preset vehicle condition.

3. The OTA update method according to claim 1, characterized in that: After the step of receiving the OTA update task, the method further includes: In the case where the execution time is longer than the vehicle pre-verification time, executing the preset vehicle pre-update verification; After the preset vehicle pre-update verification passes, the OTA update task is executed.

4. The OTA update method according to claim 3, characterized in that: The step of performing the preset vehicle pre-update verification comprises: Obtaining vehicle information of the vehicle; When the vehicle information satisfies the verification items of the preset vehicle pre-update verification, it is determined that the preset vehicle pre-update verification has passed, wherein the verification items of the preset vehicle pre-update verification include at least one of: the vehicle has obtained update authorization, the identity of the vehicle is the same as the task vehicle identity of the OTA update task, there are no occupants in the vehicle, the power of the vehicle is active, the three-electric system of the vehicle enters the OTA state, the anti-theft system of the vehicle is normal, the vehicle is in the vehicle locked, each update unit corresponding to the OTA update task in the vehicle is online, the preset update unit among the update units has received the update file key, the management module of the vehicle enters the OTA state, and the fault code of the vehicle has been cleared.

5. The OTA update method according to claim 1, characterized in that: The step of determining the execution time for the vehicle to complete the OTA update task includes: Determine a local update duration required for updating each update unit corresponding to the OTA update task in the vehicle; The execution time for the vehicle to complete the OTA update task is determined based on the duration of each local update.

6. The OTA update method according to claim 5, characterized in that: The step of determining the execution time of the vehicle to complete the OTA update task based on each local update time includes: Based on the current vehicle usage scenario of the vehicle, determining an ignored update unit among the update units, wherein the ignored update unit is an update unit whose usage probability in the current vehicle usage scenario is less than a preset threshold; Eliminate the local update duration of the ignored update unit from each of the local update durations to obtain a target local update duration collection; Based on the longest local update duration in the target local update duration collection, determine the execution duration for the vehicle to complete the OTA update task.

7. An OTA update device, characterized in that: The OTA update device comprises: A determination module, configured to receive an OTA update task and determine an execution time for the vehicle to complete the OTA update task; A skipping module, configured to skip the preset vehicle pre-update verification if the execution time is less than or equal to the verification time required to execute the preset vehicle pre-update verification; An execution module is used to execute the OTA update task.

8. A vehicle, characterized in that: The vehicle comprises: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the OTA update method according to any one of claims 1 to 6.

9. A storage medium, characterized in that: 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, the steps of the OTA update method according to any one of claims 1 to 6 are implemented.

10. A computer program product, characterized in that The computer program product comprises a computer program, and when the computer program is executed by a processor, the steps of the OTA update method according to any one of claims 1 to 6 are implemented.

Images