OTA updating method, vehicle, storage medium and product

By checking and pre-update verification of vehicle conditions in vehicle OTA upgrade technology, some original pre-update verification conditions are eliminated, and the problem of long upgrade time of vehicle OTA is solved, which improves the user's car use experience.

CN119473350APending Publication Date: 2025-02-18ZHEJIANG ZEEKR INTELLIGENT TECH CO LTD +1
View PDF 0 Cites 1 Cited by

Patent Information

Application Number
CN202411525452.1
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2024-10-29
Publication Date
2025-02-18

AI Technical Summary

Technical Problem

The existing vehicle OTA upgrade technology has a long upgrade time in actual applications, which affects the user's vehicle experience.

Method used

After receiving the OTA update task, the current vehicle status of the vehicle is obtained and pre-update verification is performed when the preset vehicle conditions are met. By eliminating some of the original pre-checking conditions, the content of pre-checking is reduced, thereby shortening the vehicle update cycle on the user's senses.

Benefits of technology

By reducing the content of pre-update verification, the time when users cannot use the vehicle is shortened, the user's car usage experience is improved, and the vehicle update cycle is shortened.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119473350A_ABST
    Figure CN119473350A_ABST
Patent Text Reader

Abstract

The invention discloses an OTA updating method, a vehicle, a storage medium and a product, and relates to the technical field of OTA. The method comprises the steps that after an OTA updating task is received, the current vehicle state of the vehicle is acquired; under the condition that the current vehicle state meets a preset vehicle condition, pre-update verification is conducted on the vehicle, the preset vehicle condition comprises a change condition obtained by changing a verification condition in preset original pre-verification, and the pre-update verification is obtained by removing the change condition in the preset original pre-verification; and after verification is passed before updating, executing the OTA updating task. The content of verification before updating is reduced, so that the duration that the user cannot use the vehicle in the vehicle updating and upgrading process is shortened, the vehicle updating period of the user in sense is shortened under the condition that the verification before updating is carried out, and the vehicle using experience of the user is improved.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

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

[0002] OTA (Over-the-Air Technology) refers to the use of the network to remotely update system software. With the increasing popularity of OTA technology 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-checked. It should be noted that the pre-check process also takes time, and during the pre-check process the vehicle will enter the BOOT state (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-check as the cycle of 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.

[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] After receiving the OTA update task, obtain the current vehicle status of the vehicle;

[0007] In the case where the current vehicle state satisfies a preset vehicle condition, performing a pre-update check on the vehicle, wherein the preset vehicle condition includes a changed condition obtained by changing a check condition in a preset original pre-check, and the pre-update check is obtained by removing a check condition in the preset original pre-check that corresponds to the changed condition;

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

[0009] Optionally, after the step of obtaining the current vehicle state of the vehicle, the method further includes:

[0010] In the case where the current vehicle state does not satisfy the preset vehicle condition, determining prompt information based on target state information in the current vehicle state that does not satisfy the preset vehicle condition;

[0011] The prompt information is outputted through the vehicle computer screen.

[0012] Optionally, the step of performing pre-update verification on the vehicle includes:

[0013] Obtaining vehicle information of the vehicle;

[0014] When the vehicle information satisfies the verification conditions of the pre-update verification, it is determined that the pre-update verification has passed, wherein the verification conditions of the 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 vehicle locked, each update unit corresponding to the OTA update task in the vehicle is online, the preset update unit in each update unit 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, wherein each update unit is an electronic control unit for controlling the vehicle.

[0015] Optionally, the step of executing the OTA update task includes:

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

[0017] Writing the target update data into the data storage area of ​​the update unit, and verifying the data stored in the data storage area after writing is completed;

[0018] After the verification is passed, the updating of the updating unit is completed.

[0019] Optionally, after the step of determining the target update data corresponding to the update unit, the method includes:

[0020] 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, 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.

[0021] Optionally, before the step of writing the target update data into the data storage area of ​​the update unit, the method includes:

[0022] Determine a collaborative unit related to the update unit based on a preset collaborative unit mapping table;

[0023] The unit function of the update unit and the unit function of the coordination unit are turned off, wherein the unit function of the update unit is re-enabled after the update of the update unit and the coordination unit that needs to be updated finishes updating.

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

[0025] An acquisition module, used to obtain the current vehicle status of the vehicle after receiving the OTA update task;

[0026] a verification module, configured to perform a pre-update verification on the vehicle if the current vehicle state satisfies a preset vehicle condition, wherein the preset vehicle condition includes a changed condition obtained by changing a verification condition in a preset original pre-verification, and the pre-update verification is obtained by removing a verification condition corresponding to the changed condition in the preset original pre-verification;

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

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

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

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

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

[0032] In an embodiment of the present application, after receiving the OTA update task, the current vehicle state of the vehicle is obtained; when the current vehicle state meets the preset vehicle conditions, the vehicle is pre-updated and verified, wherein the preset vehicle conditions include the change conditions obtained by changing the verification conditions in the preset original pre-verification, and the pre-update verification is obtained by eliminating the verification conditions corresponding to the change conditions in the preset original pre-verification; after the pre-update verification passes, the OTA update task is executed. That is, before the OTA update of the vehicle, the vehicle condition check and pre-verification will be performed on the vehicle in this embodiment, but compared with the existing vehicle OTA upgrade technology, the part of the content placed in the pre-verification will be transferred to the vehicle condition check process in advance, and the vehicle condition check process will not enter the BOOT state and can be used normally, and the OTA update task will be executed after passing the pre-verification. It can be understood that since the content of the pre-update verification is reduced, the time that the user cannot use the vehicle during the vehicle update and upgrade process is also reduced, and the vehicle update cycle perceived by the user is shortened in the case of pre-verification, thereby improving the user's car experience. BRIEF DESCRIPTION OF THE DRAWINGS

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

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

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

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

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

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

[0039] Figure 5 This is a first structural diagram corresponding to the OTA update device of this application;

[0040] Figure 6This is a second structural diagram corresponding to the OTA update device of this application;

[0041] Figure 7 This 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.

[0042] 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

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

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

[0045] 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 during the pre-verification process the vehicle will enter the BOOT state (the user will not be able to use the vehicle normally in the BOOT state). For the user, the time spent on the pre-verification will be used 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.

[0046] The main solution of the embodiment of the present application is: after receiving the OTA update task, obtain the current vehicle status of the vehicle; when the current vehicle status meets the preset vehicle conditions, perform a pre-update check on the vehicle, wherein the preset vehicle conditions include change conditions obtained by changing the check conditions in the preset original pre-check, and the pre-update check is obtained by eliminating the check conditions corresponding to the change conditions in the preset original pre-check; after the pre-update check passes, execute the OTA update task.

[0047] That is, this embodiment will also perform a vehicle condition check and pre-verification on the vehicle before performing an OTA update. However, compared with the existing vehicle OTA upgrade technology, this embodiment will pre-transfer some of the content placed in the pre-verification to the vehicle condition check process, and perform the OTA update task after passing the pre-verification. It can be understood that since the content of the pre-update verification is reduced, the length of time that the user cannot use the vehicle during the vehicle update and upgrade process is also reduced, and the vehicle update cycle perceived by the user is shortened in the case of pre-verification, thereby improving the user's vehicle experience.

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

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

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

[0051] Step S10, after receiving the OTA update task, obtaining the current vehicle status of the vehicle;

[0052] It should be noted that, in this embodiment, the above-mentioned OTA update method is usually applied to vehicles. The OTA update task is usually used to update the software system on the vehicle, wherein the OTA update task can be sent to the vehicle by the cloud associated with the vehicle. Among them, the OTA update task usually carries update data packets 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 time required for each update unit, etc. The specific content can be set by the technician and will not be repeated here.

[0053] Exemplarily, the vehicle can receive the OTA update task sent from the cloud, and then obtain its current vehicle status, and the current vehicle status is used for vehicle condition checking, which is one of the steps to determine whether the vehicle has the update conditions. It is worth noting that the vehicle needs to be authorized by the user before preparing for the update (that is, the user needs to agree to update the vehicle). For example, after receiving the OTA update task, the vehicle can display the upgrade (update) prompt information through the vehicle computer on the vehicle, and the prompt information may include the options of immediate upgrade and scheduled upgrade. If the user chooses the option of immediate upgrade, the vehicle can start the upgrade preparation work. If the user chooses the option of scheduled upgrade, the vehicle needs to wait until the scheduled time period before preparing for the upgrade. The specific content of the current vehicle status obtained above is determined by the preset vehicle conditions that need to be checked later. For example, if the preset vehicle conditions in the subsequent steps include that the vehicle is less than the preset speed, the current vehicle status obtained includes the vehicle's driving speed; if the preset vehicle conditions include that the vehicle is in a parking gear, the current vehicle status obtained includes the vehicle's gear information.

[0054] Step S20, when the current vehicle state satisfies a preset vehicle condition, performing a pre-update check on the vehicle, wherein the preset vehicle condition includes a changed condition obtained by changing a check condition in a preset original pre-check, and the pre-update check is obtained by removing a check condition in the preset original pre-check that corresponds to the changed condition;

[0055] It should be noted that during the vehicle condition check, the vehicle will not enter the BOOT state. Therefore, during the vehicle condition check stage, the vehicle can be used normally by the user. When the vehicle does not enter the BOOT state during the condition check, the vehicle signal interaction is through application messages. After the vehicle enters the BOOT state, the FOTAMaster (Firmware Over the 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, Diagnostics based on Internet Protocol) messages. Therefore, the process of vehicle condition inspection and pre-verification can be divided before the vehicle is updated. At the same time, the vehicle condition inspection stage will not affect the normal use of the vehicle by the user. Therefore, for the user, the time spent in the vehicle condition inspection stage will not be included in the entire update cycle.

[0056] Exemplarily, after obtaining the current vehicle state of the vehicle, the current vehicle state is compared with the preset vehicle condition to determine whether the current vehicle state meets the preset vehicle condition. If it is determined that the current vehicle state meets the preset vehicle condition, the pre-update check is performed, otherwise, the vehicle condition check fails. Among them, the above-mentioned preset vehicle condition includes the change condition obtained by changing the check condition in the preset original pre-check, and the pre-update check is determined by removing the preset original pre-check corresponding to the check condition of the change condition. That is, in this embodiment, some of the check conditions 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 condition corresponding to the change condition removed can also be directly used as the above-mentioned pre-update check. The above-mentioned change condition can 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 conditions in the preset original pre-check). In addition to the change condition, the preset vehicle condition can 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. That is, the current vehicle status obtained can be determined by the preset vehicle conditions, so the specific vehicle status will not be described here. In addition, it should be noted that in this embodiment, some 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 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, reduce the length of time that the user cannot use the vehicle during the vehicle upgrade process, and shorten the vehicle update cycle perceived by the user in the case of pre-verification.

[0057] In addition, during the pre-update verification process, the vehicle information of the vehicle can also be obtained according to the verification conditions in the pre-update verification, and the vehicle information can be compared with the verification conditions. If the verification conditions are met, it can be determined that the vehicle has passed the pre-verification. The specific verification conditions for the pre-update verification can be set by the technician.

[0058] Step S30, after the pre-update verification passes, executing the OTA update task.

[0059] Exemplarily, if the vehicle passes the pre-update verification, it means that the current vehicle is eligible for updating, and accordingly, the OTA update task can be executed. The process of executing the OTA update task may include: backing up the current system so that it can be restored to its 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 receiving the OTA update task, the current vehicle state of the vehicle is obtained; when the current vehicle state meets the preset vehicle conditions, the vehicle is checked before the update, wherein the preset vehicle conditions include the change conditions obtained by changing the check conditions in the preset original pre-check, and the pre-update check is obtained by eliminating the check conditions corresponding to the change conditions in the preset original pre-check; after the pre-update check passes, the OTA update task is executed. That is, this embodiment will also perform a vehicle condition check and pre-check on the vehicle before performing an OTA update on the vehicle, but compared with the existing vehicle OTA upgrade technology, this embodiment will transfer part of the content placed in the pre-check to the vehicle condition check process in advance, and execute the OTA update task after passing the pre-check. It can be understood that since the content of the pre-update check is reduced, the length of time that the user cannot use the vehicle during the vehicle update and upgrade process is also reduced, which shortens the vehicle update cycle perceived by the user and improves the user's car experience when the pre-check is performed.

[0061] In a feasible implementation manner, before the step of performing a pre-update verification on the vehicle, the method includes:

[0062] 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-verification time, execute the step of performing the pre-update verification on the vehicle.

[0063] For example, in actual applications, the cloud can also calculate the execution time of the OTA update task first, 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 update, the execution time can be calculated by accumulating each update time. If it is a parallel update, the execution time can be determined by the longest update time. The verification time required for the above-mentioned 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 then the average time can be used as the above-mentioned verification time. Then compare the size between the execution time and the verification time to determine whether to skip the pre-verification part.

[0064] It is understandable that the purpose of the 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 where the actual update time is long, a certain amount of extra time can be spent on the pre-verification to reduce 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 wasted due to the failure of the update midway. Therefore, the pre-verification operation performed at this time cannot achieve 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, thereby improving the user's car experience.

[0065] In a feasible implementation manner, after the step of obtaining the current vehicle state of the vehicle, the method further includes steps S01 to S02:

[0066] Step S01, when the current vehicle state does not satisfy the preset vehicle condition, determining prompt information based on target state information in the current vehicle state that does not satisfy the preset vehicle condition;

[0067] Step S02: outputting the prompt information through the vehicle screen.

[0068] For example, since the process of generating prompt information based on each target state information is roughly similar, in this embodiment, one target state information is used as an example for description. 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.

[0069] Reference 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 that the vehicle is in the parking gear and the current vehicle is driving, the vehicle screen can output the following information: Figure 2 The prompt information interface shown. Figure 3 , which is a schematic diagram of the second output scenario of the prompt information in this application. If the preset vehicle condition includes the vehicle scenario mode being turned off, and the scenario mode is currently turned on, the vehicle screen can output the following information: Figure 3 The prompt information interface shown.

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

[0071] In a feasible implementation manner, the step of performing pre-update verification on the vehicle includes steps S21 to S22:

[0072] Step S21, obtaining vehicle information of the vehicle;

[0073] Step S22, when the vehicle information satisfies the verification conditions of the pre-update verification, determine that the pre-update verification has passed, wherein the verification conditions of the 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 vehicle locked, each update unit corresponding to the OTA update task in the vehicle is online, the preset update unit in each update unit 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, wherein each update unit is an electronic control unit for controlling the vehicle.

[0074] Exemplarily, the steps of 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 conditions in the pre-verification. When the verification conditions include that there are no occupants in the vehicle, the vehicle information may include the number of occupants in the vehicle. When the verification conditions 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.

[0075] The obtained vehicle information is compared with the verification conditions of the pre-update verification. If the vehicle information meets the verification conditions of the pre-update verification, it can be determined that the pre-update verification has passed. Among them, the verification conditions at least include that the vehicle has obtained the update authorization, the identity of the vehicle is the same as the task vehicle identity of the OTA update task, there are no passengers 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 lock, each update unit corresponding to the OTA update task in the vehicle is online, the preset update unit in each update unit 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. At least one of the above, wherein each update unit is an electronic control unit that controls the vehicle and needs to be updated, such as an engine control unit, an automatic transmission control unit, a body control module, a body electronic stability control unit, a battery management unit, a vehicle controller, and a hydraulic control unit, etc., which will not be repeated here. It should be noted that the verification conditions can be freely combined by the technicians according to the above conditions, or in order to avoid risks, it is preferred that the verification conditions include the above conditions.

[0076] Furthermore, the verification condition is: the vehicle has obtained the update authorization, and the corresponding verification process is that the vehicle outputs the option of whether to update through the HMI (Human-Machine 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, there is a regret period. 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.

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

[0078] Verification conditions: There are no passengers in the vehicle, and 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 process. If people perform some unbanned operations (i.e. high-authority operations, such as braking) in the car, the vehicle upgrade may fail. This verification condition can be set according to the functional conditions of different projects and different models (some models may be configured with life detection).

[0079] Verification conditions: The vehicle's power is in active state. The corresponding verification process is to check the power mode. This process is to check the vehicle's power mode. After the regret time is over, the vehicle's power mode must be inactive (active state). If the power mode is not met, the OTA update task is postponed.

[0080] Verification conditions: 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), motor control system (MCU) and vehicle control unit (VCU). When these systems enter the OTA state, it means that the vehicle is receiving or preparing to receive remote software updates from the manufacturer.

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

[0082] Verification conditions: The vehicle is in the state of vehicle lock. The corresponding verification process is to check whether the vehicle is locked. This process is that the FOTA Master sends a diagnostic command to the domain control of the vehicle body to check whether the lock status of the vehicle is locked.

[0083] Verification conditions: All update units in the vehicle corresponding to the OTA update task are online. The corresponding verification process is to check the online status of the vehicle ECU. This process is that the FOTA Master sends a diagnostic command to the vehicle ECU to confirm the status 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.

[0084] 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 (ie, 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.

[0085] Verification conditions: the vehicle's management module enters the OTA state and the vehicle's fault code has been cleared. The corresponding verification process is to prepare for clearing DTC (Diagnostic Trouble Code), which is to record and clear the vehicle's existing DTC.

[0086] In addition to the above, the verification conditions before the update can also include checking the OTA pre-sale / after-sale process, which is to check the status of the vehicle, which is divided into pre-sale vehicles and after-sale vehicles. If the vehicle status is a pre-sale vehicle, it is not necessary to meet the verification condition that the vehicle's identity is the same as the task vehicle identity 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.

[0087] It is worth noting that the above 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.

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

[0089] Reference Figure 4 Based on the first embodiment of the OTA update method of the present application, the second embodiment of the present application is proposed. The same or similar contents as the above embodiments in this embodiment can be referred to the above introduction, and will not be repeated later. The step of executing the OTA update task includes steps S31 to S33:

[0090] Step S31, for any one of the update units corresponding to the OTA update task, determining target update data corresponding to the update unit;

[0091] Step S32, writing the target update data into the data storage area of ​​the update unit, and verifying the data stored in the data storage area after writing is completed;

[0092] Step S33, after the verification is passed, the updating of the updating unit is completed.

[0093] It should be noted that the above OTA update task usually involves updating multiple ECUs on the vehicle, that is, multiple control units, and the control unit that needs to be updated is the update unit. In addition, since the processing method of each update unit is the same, in this embodiment, one of the update units will be used as an example for explanation.

[0094] Exemplarily, for any one of the update units corresponding to the OTA update task, the target update data corresponding to the update unit is determined. It can be understood that when the OTA update task is received, the data update package can be downloaded synchronously, and different identifiers can be set for data packets for different update units. Therefore, the target update data corresponding to the above update unit can be found from the downloaded data update package through the identifier pre-set by the above update unit. Then, the above update unit is flashed based on the target update data, that is, the target update data is written to the data storage area of ​​the above update unit. After the writing is completed, the data stored in the data storage area is verified to ensure that the writing is correct. For example, the verification method can be a CRC check (Cyclic Redundancy Check), and after the verification passes, it can be characterized that the update unit has completed the update. Each update unit can be updated with reference to the above process, so it will not be repeated here.

[0095] In a feasible implementation manner, after the step of determining the target update data corresponding to the update unit, the method includes step S34:

[0096] 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, 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.

[0097] Exemplarily, if an error occurs when writing the target update data to the data storage area of ​​the above-mentioned update unit, it can be considered that the target update data fails to be written to the data storage area, or, after an error occurs when writing the target update data to the data storage area of ​​the above-mentioned update unit, the target update data is retried to be written to the data storage area, and after the number of attempts reaches a preset number, it is determined that the target update data fails to be written to the data storage area. In addition, if the data stored in the data storage area fails to be verified, it can be characterized as a data verification failure, or, after the data stored in the data storage area fails to be verified, the writing and verification are retried, and after the number of attempts to write and verify reaches a preset number, it is determined that the data verification of the access to the storage area fails. In the case 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 is used to overwrite the data stored in the above-mentioned data storage area with the historical data in the data backup area to roll back the system version of the update unit, thereby ensuring that in the case of failure to update the above-mentioned update unit, the update unit can still use the old version of the system to provide its original function. In addition, before writing the target update data to the data storage area, the data in the data storage area can be backed up to the above-mentioned data backup area to form historical data.

[0098] In a feasible implementation manner, before the step of writing the target update data into the data storage area of ​​the update unit, the method includes steps S301 to S302:

[0099] Step S301, determining a collaborative unit related to the update unit based on a preset collaborative unit mapping table;

[0100] Step S302, shutting down the unit function of the update unit and the unit function of the coordination unit, wherein after the update unit and the coordination unit that needs to be updated finish updating, the unit function of the update unit is re-enabled.

[0101] It should be noted that, in this embodiment, in order to avoid mutual influence between the upgraded control unit (ie the above-mentioned update) and the control unit that does not need to be upgraded during the upgrade process, in this embodiment, the unit function of the update unit will be adaptively turned off.

[0102] Exemplarily, for the above-mentioned update unit, before actually writing the target update data of the update unit into the data storage area of ​​the update unit, it is necessary to determine the related units that have a collaborative relationship with the update unit, that is, the above-mentioned collaborative units. The collaborative units related to the update unit can be determined by a preset collaborative unit mapping table, wherein the preset collaborative unit mapping table can be set by a technician according to the relationship between units in the vehicle, and the core unit in the vehicle - the engine control unit - is used as an example for explanation. The transmission control unit, the brake control unit, the electronic stability program control unit, and the battery management system, etc., that have a collaborative relationship with the engine control unit in the vehicle, accordingly, the collaborative relationship between the engine control unit and the above-mentioned units and systems can be recorded in the preset collaborative unit mapping table.

[0103] Furthermore, after determining the collaborative unit, the unit functions of the above-mentioned update unit and the unit functions of the collaborative unit are turned off, so as to avoid the mutual influence between the update unit and each collaborative unit during the upgrade process, such as the collaborative unit affecting the update of the update unit, or the update unit causing the collaborative unit to make errors during the upgrade process. After waiting for the update unit to complete the update, and the collaborative unit that needs to be updated in each collaborative unit to complete the update, the unit function of the update unit can be re-enabled, and the unit function of the adaptive collaborative unit can also be enabled.

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

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

[0106] A verification module 20, configured to perform a pre-update verification on the vehicle when the current vehicle state satisfies a preset vehicle condition, wherein the preset vehicle condition includes a changed condition obtained by changing a verification condition in a preset original pre-verification, and the pre-update verification is obtained by removing a verification condition corresponding to the changed condition in the preset original pre-verification;

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

[0108] Optionally, refer to Figure 6 The OTA update device further includes a prompt module 40, and the prompt module 40 is used to:

[0109] In the case where the current vehicle state does not satisfy the preset vehicle condition, determining prompt information based on target state information in the current vehicle state that does not satisfy the preset vehicle condition;

[0110] The prompt information is outputted through the vehicle computer screen.

[0111] Optionally, the verification module 20 is further used for:

[0112] Obtaining vehicle information of the vehicle;

[0113] When the vehicle information satisfies the verification conditions of the pre-update verification, it is determined that the pre-update verification has passed, wherein the verification conditions of the 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 vehicle locked, each update unit corresponding to the OTA update task in the vehicle is online, the preset update unit in each update unit 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, wherein each update unit is an electronic control unit for controlling the vehicle.

[0114] Optionally, the execution module 30 further includes:

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

[0116] Writing the target update data into the data storage area of ​​the update unit, and verifying the data stored in the data storage area after writing is completed;

[0117] After the verification is passed, the updating of the updating unit is completed.

[0118] Optionally, the execution module 30 further includes:

[0119] 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, 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.

[0120] Optionally, the execution module 30 further includes:

[0121] Determine a collaborative unit related to the update unit based on a preset collaborative unit mapping table;

[0122] The unit function of the update unit and the unit function of the coordination unit are turned off, wherein the unit function of the update unit is re-enabled after the update of the update unit and the coordination unit that needs to be updated finishes updating.

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

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

[0125] Reference below Figure 7 , which shows a schematic structural diagram of a vehicle suitable for implementing an embodiment of the present application. Figure 7 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.

[0126] like Figure 7As 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.

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

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

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

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

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

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

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

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

[0135] After receiving the OTA update task, obtain the current vehicle status of the vehicle;

[0136] In the case where the current vehicle state satisfies a preset vehicle condition, performing a pre-update check on the vehicle, wherein the preset vehicle condition includes a changed condition obtained by changing a check condition in a preset original pre-check, and the pre-update check is obtained by removing a check condition in the preset original pre-check that corresponds to the changed condition;

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

[0138] 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).

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

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

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

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

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

[0144] 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: After receiving the OTA update task, obtain the current vehicle status of the vehicle; In the case where the current vehicle state satisfies a preset vehicle condition, performing a pre-update check on the vehicle, wherein the preset vehicle condition includes a changed condition obtained by changing a check condition in a preset original pre-check, and the pre-update check is obtained by removing a check condition in the preset original pre-check that corresponds to the changed condition; After the pre-update verification passes, the OTA update task is executed.

2. The OTA update method according to claim 1, characterized in that: After the step of obtaining the current vehicle state of the vehicle, the method further includes: In the case where the current vehicle state does not satisfy the preset vehicle condition, determining prompt information based on target state information in the current vehicle state that does not satisfy the preset vehicle condition; The prompt information is outputted through the vehicle computer screen.

3. The OTA update method according to claim 1, characterized in that: The step of performing pre-update verification on the vehicle comprises: Obtaining vehicle information of the vehicle; When the vehicle information satisfies the verification conditions of the pre-update verification, it is determined that the pre-update verification has passed, wherein the verification conditions of the 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 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 management module of the vehicle enters the OTA state, and the fault code of the vehicle has been cleared, wherein each update unit is an electronic control unit for controlling the vehicle.

4. The OTA update method according to claim 1, characterized in that: The step of executing the OTA update task includes: For any one of the update units corresponding to the OTA update task, determine the target update data corresponding to the update unit; Writing the target update data into the data storage area of ​​the update unit, and verifying the data stored in the data storage area after writing is completed; After the verification is passed, the updating of the updating unit is completed.

5. The OTA update method according to claim 4, characterized in that: After the step of determining the target update data corresponding to the update unit, the method comprises: 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, 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.

6. The OTA update method according to claim 4, characterized in that: Before the step of writing the target update data into the data storage area of ​​the update unit, the method includes: Determine a collaborative unit related to the update unit based on a preset collaborative unit mapping table; The unit function of the update unit and the unit function of the coordination unit are turned off, wherein the unit function of the update unit is re-enabled after the update of the update unit and the coordination unit that needs to be updated finishes updating.

7. An OTA update device, characterized in that: The OTA update device comprises: An acquisition module, used to obtain the current vehicle status of the vehicle after receiving the OTA update task; a verification module, configured to perform a pre-update verification on the vehicle if the current vehicle state satisfies a preset vehicle condition, wherein the preset vehicle condition includes a changed condition obtained by changing a verification condition in a preset original pre-verification, and the pre-update verification is obtained by removing a verification condition corresponding to the changed condition in the preset original pre-verification; The execution module is used to execute the OTA update task after the pre-update verification is passed.

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.

Citation Information

Cited By

  • OTA update method, vehicle, storage medium, and product

    WO2026091496A1