Vehicle upgrading method and vehicle

Abstract

A vehicle upgrading method and a vehicle, relating to the technical field of vehicle control. The vehicle comprises at least one controller including a first controller, and the method can address the situation where there is a controller that fails to upgrade during vehicle upgrade. In this situation, the first controller can start a wake-up timing operation and control the vehicle to power off, and after the wake-up timing operation is finished, the vehicle is powered on, and the first controller is awoken. Then, the first controller re-upgrades the at least one controller, i.e., upgrading the vehicle again. After the vehicle is powered on, the at least one controller is reset, and the communication link re-established after resetting is generally normal. When the communication link is normal, the probability of successful upgrade of all the controllers also increases.

Description

Vehicle upgrade methods and vehicles

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office on December 29, 2023, with application number 202311866584.6 and application name “Method and Vehicle for Upgrading Whole Vehicles”, all contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of vehicle control technology, and in particular to a method for upgrading a whole vehicle and a vehicle. Background Art

[0003] A vehicle consists of multiple functional domains, such as the cockpit, body, chassis, and powertrain. Each domain can include different vehicle components, and each domain has a corresponding domain controller. A domain controller can control the vehicle components in its corresponding domain to implement certain functions. Furthermore, the cockpit domain controller can control other domain controllers, thereby achieving functional linkage across the entire vehicle.

[0004] To improve vehicle functionality and performance, fix vulnerabilities, and more, the entire vehicle can be remotely upgraded (over the air, OTA) during the vehicle's power cycle. During the OTA process, the vehicle retrieves and installs a new software package from a cloud server, thereby upgrading the functionality or performance of each domain controller on the vehicle. However, this current upgrade method can cause some domain controllers to fail due to communication link anomalies.

[0005] Summary of the Invention

[0006] The present application provides a method and vehicle for upgrading a whole vehicle, which can increase the probability of successful upgrading of the whole vehicle and improve the user experience.

[0007] To achieve the above objectives, this application adopts the following technical solutions:

[0008] In a first aspect, a method for upgrading a whole vehicle is provided, which is applied to a first controller of a vehicle. The vehicle includes at least one controller, including the first controller. In the method, the first controller upgrades the at least one controller. If the upgrade fails during the upgrade process, the first controller initiates a wake-up timer and powers off the vehicle. The wake-up timer is configured to time the vehicle, and upon expiration of the timer, powers on the vehicle and wakes up the first controller. The first controller then re-upgrades the at least one controller.

[0009] In the above method, after the vehicle is powered off and then on again, at least one controller on the vehicle is reset, and the communication links reestablished after these controllers are reset are generally normal. If the communication links are normal, the first controller will upgrade at least one controller again, thereby increasing the probability of successful upgrades for all controllers. Furthermore, if the communication links are normal, controllers that failed to upgrade will also successfully respond to diagnostic requests, thereby increasing the diagnostic success rate for those controllers, enabling more accurate analysis of the cause of upgrade anomalies based on the diagnostic results, and improving the success rate of resolving upgrade anomalies, thereby increasing the success rate of re-upgrading controllers that failed to upgrade.

[0010] The reset includes restarting, resetting, or re-writing the internal firmware or other specific execution methods with the same function, which are not limited here.

[0011] Therefore, in the above method provided by the present application, after the entire vehicle is powered off and then powered on again, the upgrade operation on at least one controller is performed again, which can increase the probability of successful controller upgrade, further ensure that the functions or performance of the entire vehicle can be updated, and improve the user experience.

[0012] In an implementation of the first aspect, when a controller upgrade fails during the upgrade process, the first controller determines a vehicle state, and when the vehicle is in an armed state, the first controller starts a wake-up timing operation and controls the vehicle to power off.

[0013] In this implementation, since the armed state indicates that the vehicle is locked, when the vehicle is locked, it is highly likely that the vehicle will not start, and no user will use the vehicle's internal central control screen or operate vehicle components. Therefore, starting the wake-up timer in this state and re-upgrading after the timer ends can reduce the situation where the upgrade is interrupted by vehicle startup, user operation, etc., and ensure the smooth progress of the entire vehicle upgrade.

[0014] In one implementation of the first aspect, after determining the above-mentioned vehicle status, when the vehicle is in an unarmed state, the first controller presents information for prompting that the entire vehicle upgrade has failed.

[0015] In this implementation, since the vehicle may be started or operated at any time in the disarmed state, the first controller will not upgrade the vehicle again in the disarmed state, thereby reducing the interruption of the upgrade and improving the user experience.

[0016] In one implementation of the first aspect, during the wake-up timing operation, if the vehicle switches from an armed state to a disarmed state, the first controller presents information indicating that the vehicle upgrade has failed.

[0017] In this implementation, since the vehicle state changes, it cannot be guaranteed that the whole vehicle upgrade can proceed smoothly and will not be interrupted. Therefore, the first controller terminates the whole vehicle upgrade operation.

[0018] In one implementation of the first aspect, when the vehicle is in an armed state, the first controller may first obtain a first retry count for an upgrade operation, where the first retry count indicates the number of times the upgrade operation is re-performed on at least one controller. When the first retry count is greater than zero, the first controller initiates a wake-up timer and controls the vehicle to power off.

[0019] In this implementation, if the first retry count is non-zero, it indicates that the number of retries for upgrading at least one controller (or upgrading the entire vehicle) has not been exhausted. In this case, the upgrade operation can be attempted again to increase the probability of successful controller upgrade. If the first retry count is zero, it indicates that the number of retries for upgrading at least one controller (or upgrading the entire vehicle) has been exhausted. In this case, to avoid wasting unnecessary time by repeatedly retrying, no further retries will be made when the number of retries is exhausted.

[0020] In one implementation of the first aspect, when the first retry count is zero, the first controller presents a message indicating that the vehicle upgrade has failed, thereby notifying the user of the vehicle upgrade failure so that the user can handle the issue on their own or seek technical assistance.

[0021] In one implementation of the first aspect, during the process of upgrading at least one controller by the first controller, if the vehicle meets a first preset condition, the first controller upgrades the at least one controller based on a received upgrade software package for the entire vehicle. The first preset condition includes one or more of the vehicle being stationary, the vehicle not being started, and the vehicle being in a preset gear position. When the at least one controller is successfully upgraded, the first controller displays a message indicating the successful upgrade of the entire vehicle.

[0022] In this implementation, the first preset condition can ensure that the entire vehicle is upgraded when the vehicle is in a suitable state, thereby reducing the impact of the entire vehicle upgrade process on the user's driving or the user's use of the vehicle.

[0023] In one implementation of the first aspect, when upgrading a controller, if the controller upgrade fails and the vehicle meets a second preset condition, the first controller obtains a second retry count for the controller upgrade operation, where the second preset condition includes the vehicle being in an unstartable state and / or the vehicle having doors that cannot be opened. When the second retry count is greater than zero, the controller is re-upgraded. When the second retry count is equal to zero, the controller upgrade is determined to have failed.

[0024] In this implementation, the second preset condition can avoid upgrading the entire vehicle again when a serious fault or situation occurs in the vehicle, reducing the number of retries and saving time.

[0025] In a second aspect, a vehicle is provided, comprising at least one controller including a first controller.

[0026] A first controller is configured to upgrade at least one controller; when an upgrade of a controller fails during the upgrade process, control the remote communication controller to initiate a wake-up timing operation and control the vehicle to power off; the wake-up timing operation is configured to time, and when the timer expires, control the vehicle to power on and wake up the first controller;

[0027] The first controller is further used to re-upgrade at least one controller.

[0028] In a third aspect, a vehicle is provided, comprising a memory and one or more controllers; the memory is coupled to the controller; wherein computer program code is stored in the memory, and the computer program code comprises computer instructions, which, when executed by the controller, enable the vehicle to execute the method for whole-vehicle upgrade as described in the first aspect and any implementation thereof.

[0029] In a fourth aspect, a computer-readable storage medium is provided, comprising computer instructions. When the computer instructions are executed on a vehicle, the vehicle executes the method for upgrading the entire vehicle as described in the first aspect and any implementation thereof.

[0030] In a fifth aspect, a computer program product is provided, which, when run on a vehicle, enables the vehicle to execute the method for upgrading the entire vehicle as described in the first aspect and any implementation thereof.

[0031] It can be understood that the beneficial effects that can be achieved by the vehicle described in the second aspect, the vehicle described in the third aspect, the computer-readable storage medium described in the fourth aspect, and the computer program product described in the fifth aspect can be referred to the beneficial effects in the first aspect and any possible design method thereof, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] FIG1 is a structural schematic diagram of a vehicle according to an embodiment of the present application;

[0033] FIG2 is a second structural diagram of a vehicle according to an embodiment of the present application;

[0034] FIG3 is a first flow chart of a vehicle upgrade process according to an embodiment of the present application;

[0035] FIG4 is a second flow chart of a vehicle upgrade process according to an embodiment of the present application;

[0036] FIG5 is a schematic diagram of a vehicle with four doors and two hoods according to an embodiment of the present application;

[0037] FIG6 is a schematic diagram of the display content of the central control screen according to an embodiment of the present application;

[0038] FIG7 is a third flow chart of a vehicle upgrade process according to an embodiment of the present application;

[0039] FIG8 is a third structural diagram of a vehicle shown in an embodiment of the present application. DETAILED DESCRIPTION

[0040] The technical solutions in the embodiments of the present application will be described below in conjunction with the drawings in the embodiments of the present application. Among them, in the description of the present application, unless otherwise specified, " / " indicates that the objects associated before and after are in an "or" relationship. For example, A / B can represent A or B; "and / or" in the present application is only a description of the association relationship of the associated objects, indicating that there can be three relationships. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone, where A and B can be singular or plural. In addition, in the description of the present application, unless otherwise specified, "multiple" refers to two or more than two. "At least one of the following" or similar expressions refers to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c, ab, ac, bc, or abc, where a, b, c can be single or multiple. In addition, in order to facilitate the clear description of the technical solutions of the embodiments of the present application, in the embodiments of the present application, words such as "first" and "second" are used to distinguish between identical or similar items with substantially the same functions and effects. Those skilled in the art will understand that words such as "first" and "second" do not limit the quantity and execution order, and words such as "first" and "second" do not necessarily limit differences. At the same time, in the embodiments of the present application, words such as "exemplary" or "for example" are used to indicate examples, illustrations or explanations. Any embodiment or design described as "exemplary" or "for example" in the embodiments of the present application should not be interpreted as being more preferred or more advantageous than other embodiments or design schemes. Specifically, the use of words such as "exemplary" or "for example" is intended to present related concepts in a concrete way for easy understanding.

[0041] In addition, the business scenarios described in the embodiments of the present application are intended to more clearly illustrate the technical solutions of the embodiments of the present application, and do not constitute a limitation on the technical solutions provided in the embodiments of the present application. Ordinary technicians in this field can know that with the emergence of new business scenarios, the technical solutions provided in the embodiments of the present application are also applicable to similar technical problems.

[0042] Most current vehicles have multiple controllers to control different vehicle components and thus achieve multiple functions. For example, a vehicle may include multiple functional domains, such as the cockpit domain, body domain, chassis domain, power domain, and autonomous driving domain. Different functional domains may include different vehicle components and their respective controllers (electronic control units, ECUs).

[0043] For example, the power domain includes the engine, electric motor, generator, power battery, gearbox, etc., and may also include a power domain controller; the body domain may include headlights, taillights, interior lights, door locks, windows, sunroof, wipers, electric trunk, smart keys, air conditioning, antennas, gateway communications, etc., and may also include a body domain controller; the chassis domain may include the suspension system, steering system, braking system, etc., and may also include a chassis domain controller; the cockpit domain may include internal devices such as the center console, seats, air conditioning, etc., and may also include a cockpit domain controller; the autonomous driving domain may include vehicle autonomous driving related components, such as sensors, etc., and may also include an autonomous driving domain controller.

[0044] In addition, the cockpit domain controller can also control other functional domain controllers, thereby realizing functional linkage of the entire vehicle.

[0045] To improve vehicle functionality, performance, and fix vulnerabilities, the entire vehicle can be remotely upgraded during its power cycle, such as via OTA. During the OTA process, the vehicle can obtain and install a new software package from the cloud server, thereby upgrading the functionality or performance of each functional domain controller on the vehicle.

[0046] Among them, when performing OTA, if a controller fails to upgrade, the controller needs to be restarted and the upgrade needs to be retried. However, after the controller is restarted during the vehicle power-on cycle, there may be problems with the communication link between the controller and the gateway, such as link failure, link abnormality, etc., which will affect the re-upgrade of the controller and still cause the controller upgrade to fail. In addition, due to problems with the communication link, the controller cannot respond to diagnostic requests from other controllers or servers for the controller, so other controllers or servers cannot diagnose the upgrade abnormality of the controller, nor can they analyze the cause of the upgrade abnormality, and thus cannot solve the problem of the controller upgrade abnormality, which will still cause the controller upgrade to fail.

[0047] If a controller upgrade fails in a vehicle, it will affect the update of the vehicle's functions or performance and affect the user experience.

[0048] Based on the above, an embodiment of the present application provides a vehicle upgrade method, which can be applied to the first controller of a vehicle, wherein the vehicle includes at least one controller including the first controller. In the vehicle upgrade method, the first controller first upgrades at least one controller. When a controller upgrade fails during the upgrade process, the first controller initiates a wake-up timing operation and controls the vehicle to power off. The wake-up timing operation is used to time, and when the timer ends, the vehicle is powered on and the first controller is awakened. Afterwards, the first controller re-upgrades at least one controller.

[0049] In the above method, if a controller upgrade fails during the vehicle upgrade process, the first controller can control the vehicle to power off and reset the controllers on the vehicle. When the vehicle is powered on again, the reset first controller will re-upgrade the other reset controllers. The first controller can also upgrade itself. It is understood that after the vehicle is powered off and then powered on again, the communication link re-established after the controller is reset is generally normal. If the communication link is normal, the first controller will upgrade at least one controller again, thereby increasing the probability of successful upgrade of all controllers.

[0050] In addition, when the communication link is normal, the probability of the controller that failed to upgrade successfully responding to the diagnostic request will also increase, thereby improving the diagnostic success rate of other controllers or servers for the controller, and being able to more accurately analyze the cause of the upgrade abnormality based on the diagnostic results, thereby improving the success rate of resolving the upgrade abnormality problem, and thus improving the success rate of re-upgrading the controller that failed to upgrade.

[0051] From the above content, it can be seen that in the embodiment of the present application, after the entire vehicle is powered off and then powered on again, re-upgrading at least one controller can increase the probability of successful controller upgrade, further ensure that the functions or performance of the entire vehicle can be updated, and improve the user experience.

[0052] The above method can be applied to a vehicle. As shown in FIG1 , the vehicle may include at least one controller. The at least one controller may further include a first controller and other controllers. Furthermore, the first controller may be connected to or communicate with the other controllers.

[0053] The first controller may be a controller that controls the upgrade of at least one vehicle controller (e.g., OTA upgrade of the vehicle), such as a cockpit controller. Other controllers may be controllers other than the cockpit controller, such as a body domain controller, a chassis domain controller, a power domain controller, an autonomous driving domain controller, and a telematics box (TBOX).

[0054] For example, as shown in Figure 2, when the cockpit controller communicates with the body domain controller, chassis domain controller, power domain controller, and autonomous driving domain controller, it can control these controllers accordingly, such as controlling them to upgrade or execute corresponding functions. Specifically, when the cockpit controller communicates with the TBOX, it can set the TBOX's timer to control the TBOX's timing. Furthermore, after the TBOX's timing operation ends, the TBOX can communicate with the cockpit controller to notify or control the cockpit controller to execute corresponding operations.

[0055] When the first controller is upgrading at least one controller, if any controller fails to upgrade, the first controller can set a TBOX timer to start the wake-up timer and control the TBOX to start the wake-up timer. Furthermore, the first controller can also control the vehicle to power off.

[0056] In the embodiment of the present application, after the vehicle (or the entire vehicle) is powered off, all vehicle components except the TBOX (including the at least one controller mentioned above) are in a shutdown state or a dormant state. The TBOX remains powered to perform the above-mentioned wake-up timing operation.

[0057] When the TBOX wake-up timing operation ends, the TBOX can communicate with the first controller and the gateway through the controller area network (CAN) bus in the vehicle to control the vehicle to power on and wake up the first controller and the gateway. Afterwards, the first controller wakes up other controllers in the vehicle based on the gateway.

[0058] Controllers that were disabled during power-off will be reset when the vehicle is powered back on. Unlike a reboot, a reset controller will return to its initial state or retain only minimal functionality. Typically, a controller reset clears its data and configuration information. Furthermore, a reset controller will reestablish communication links with other controllers and with the gateway.

[0059] In the embodiment of the present application, after the vehicle is powered off and then on again, the communication link re-established with the gateway after the controller is reset is generally normal. Alternatively, it can be understood that the probability of a normal communication link being re-established in the embodiment of the present application is higher than the probability of a normal communication link being normal after the controller is restarted during the vehicle power-on cycle described above.

[0060] When the communication link is normal, the first controller upgrades at least one controller again, thereby increasing the probability of successful upgrades for all controllers. Alternatively, when the communication link is normal, the controller that failed to upgrade will also successfully respond to the diagnostic request, thereby increasing the diagnostic success rate for the controller, and being able to more accurately analyze the cause of the upgrade anomaly based on the diagnostic results, thereby increasing the success rate of resolving the upgrade anomaly problem, and thereby increasing the success rate of re-upgrading the controller that failed to upgrade. Therefore, in the embodiment of the present application, after the vehicle is powered off and then powered on again, the upgrade operation on at least one controller is performed again, which can increase the probability of successful controller upgrades, further ensure that the functions or performance of the vehicle can be updated, and improve the user experience.

[0061] In some possible implementations, the first controller controls at least one controller to perform an upgrade (ie, an operation before the entire vehicle is powered off), and reference may be made to the method shown in FIG3 .

[0062] Prior to the upgrade, the first controller may obtain an upgrade software package for the entire vehicle upgrade. For example, the first controller may proactively obtain the upgrade software package from a server before performing the upgrade operation; alternatively, the first controller may passively receive the upgrade software package from the server and pre-store it locally for direct use during the upgrade operation. The upgrade operation may be triggered by a user performing the upgrade operation on the vehicle, or it may be triggered automatically by the first controller after detecting that the vehicle meets the upgrade requirements. This embodiment of the present application does not impose any specific limitations on this.

[0063] Before starting the upgrade installation, the first controller can also perform a countdown and perform a pre-condition check on the vehicle after the countdown ends. After the vehicle pre-condition check meets the requirements, the first controller controls the vehicle to enter OTA mode and uses the obtained upgrade software package for the entire vehicle upgrade to start upgrading at least one controller.

[0064] The aforementioned precondition checks include checking whether the vehicle is stationary, started, and in a preset gear. Furthermore, the precondition checks may satisfy one or more of the following: the vehicle is stationary, not started, and in a preset gear. This ensures that the upgrade is performed in the proper state, minimizing the impact on the user's driving or use of the vehicle during the upgrade process.

[0065] Furthermore, when the vehicle enters OTA mode, it means that the vehicle cannot be operated, for example, the user cannot operate the vehicle or start the vehicle, etc. This ensures the normal progress of the vehicle upgrade, reduces the situation where the vehicle upgrade process is interrupted by user operations, and reduces the occurrence of vehicle upgrade failures.

[0066] It is understood that upgrading the at least one controller also includes upgrading the first controller itself and upgrading the TBOX. Furthermore, when upgrading the at least one controller, the upgrades can be performed sequentially or simultaneously, and this application does not impose any specific restrictions on this.

[0067] For one of the controllers, as shown in Figure 3, if the controller is upgraded successfully, the first controller continues to confirm whether all controllers have been upgraded. If there are controllers that have not been upgraded, the first controller waits for all controllers to be upgraded. If all controllers have been upgraded successfully, the first controller presents a prompt to the user that the entire vehicle has been upgraded successfully, such as displaying content on the human machine interface (HMI) to prompt the user to experience the new version.

[0068] If the controller upgrade fails, the first controller will continue to determine whether the vehicle has a "Level 5 Failure" condition. "Level 5 Failure" means the vehicle is unable to start (i.e., power is lost) and / or the vehicle's doors cannot be opened (i.e., the key is lost). If the vehicle has a "Level 5 Failure" condition, the first controller will not be able to re-upgrade the controller that failed to upgrade. Instead, the first controller will stop the upgrade operation and will not perform a rollback of the vehicle software version (returning to the last upgraded version of the vehicle). The technician or user will be notified to handle the issue.

[0069] Among them, the inability to start the vehicle or the inability to open the doors are both serious vehicle problems. These problems are likely caused by a complete vehicle upgrade, such as a damaged upgrade software package or an upgrade anomaly. Therefore, if the vehicle encounters the above-mentioned "Level 5 Failure" situation, the first controller will not attempt to upgrade the entire vehicle again, thus avoiding further upgrade failures, reducing the number of retries, and saving time.

[0070] If the vehicle does not have a "Level 5 failure" situation, the first controller determines whether the number of retries corresponding to the controller that failed to upgrade has been used up (whether the number of retries is equal to zero). If the number of retries of the controller has been used up, the first controller cannot continue to retry the upgrade of the controller. If the number of retries of the controller has not been used up, the first controller continues to retry the upgrade of the controller and reduces the number of retries by 1.

[0071] If the controller that failed to upgrade has exhausted the number of retries and still fails to upgrade, the first controller controls the controller to roll back the software version (return to the last version upgraded by the controller) and presents a prompt that the vehicle upgrade failed, such as displaying a prompt message on the HMI.

[0072] It is understood that "Level 5 failure" during the vehicle upgrade process refers to a relatively serious, uncontrollable problem that occurs during the vehicle upgrade process, resulting in the failure of the upgrade or the failure to achieve the expected goals. The above description of "Level 5 failure" is only an example. In some other possible implementations, "Level 5 failure" may also include incompatible upgrade software packages, power outages during the upgrade process, damaged upgrade software packages, errors or abnormalities during the upgrade process, and inability to roll back to the previous version. The embodiments of this application do not specifically limit the situation of "Level 5 failure".

[0073] As can be seen from the above, for the vehicle upgrade operation in the embodiments of the present application, the first controller can implement functions such as remote upgrade control, remote upgrade condition detection, and remote upgrade display, while the TBOX can implement a timing function. Remote upgrade control means that the first controller upgrades at least one controller of the vehicle; remote upgrade condition detection means that the first controller determines whether the vehicle's preconditions meet the requirements, whether a "Level 5 failure" occurs, whether the number of retries has been exhausted, and whether the vehicle status meets the requirements; remote upgrade display means that the first controller can display a corresponding prompt message after each controller is successfully upgraded, or display a corresponding prompt message after a controller fails to upgrade.

[0074] Based on the communication between the first controller and TBOX, and the control function of the first controller over all controllers of the vehicle, the vehicle can be powered off and then on again, so that the controller is reset after powering on again, so as to improve the connectivity of the communication link between the controller and the gateway, reduce link abnormalities, and reduce abnormal communication between the controller and other controllers or servers. Therefore, after the controller is reset, the probability of successful controller upgrade is increased, further ensuring that the functions or performance of the vehicle can be updated, and improving the user experience.

[0075] Taking the whole vehicle upgrade method in the embodiment of the present application as an example based on the process shown in Figure 3 above, as shown in Figure 4, the whole vehicle upgrade method may include the following steps S401-S403.

[0076] S401: A first controller upgrades at least one controller.

[0077] The way in which the first controller upgrades at least one controller may refer to the process shown in FIG. 3 .

[0078] And, in some possible implementations, the first controller can also upgrade at least one controller separately based on the acquired upgrade software package for the whole vehicle upgrade when the vehicle meets the first preset condition. And, when the at least one controller is successfully upgraded, the first controller presents information for prompting the success of the whole vehicle upgrade. Among them, the first preset condition includes one or more of the following: the vehicle is in a stationary state, the vehicle is not started, and the gear of the vehicle is in a preset gear; or, the first preset condition can also be the above-mentioned precondition, so as to ensure that the whole vehicle upgrade is carried out in a suitable state for the vehicle, and reduce the situation where the whole vehicle upgrade process affects the user's driving or the user's use of the vehicle. The embodiment of the present application does not impose specific restrictions on the first preset condition.

[0079] In some possible implementations, when upgrading a controller, if the controller upgrade fails and the vehicle meets a second preset condition, the first controller obtains a second retry count for the controller upgrade operation; and when the second retry count is greater than zero, the first controller re-upgrades the controller, and when the second retry count is equal to zero, the first controller determines that the controller upgrade has failed.

[0080] Among them, the second preset condition includes that the vehicle is in a state where it cannot be started and / or the vehicle is in a state where the door cannot be opened; or, the second preset condition may include the above-mentioned "Level 5 failure" situation, thereby avoiding upgrading the entire vehicle again when the vehicle has a more serious fault or situation, reducing the number of retries and saving time.

[0081] S402: When a controller upgrade fails during the upgrade process, the first controller starts a wake-up timing operation and controls the vehicle to power off.

[0082] The wake-up timing operation is used to time the vehicle and, when the timer expires, to power on the vehicle and wake up the first controller. Furthermore, the timer duration in the wake-up timing operation can be set to 5-10 minutes, such as 5 minutes, 8 minutes, 10 minutes, and the like.

[0083] In some possible implementations, the first controller may control the TBOX to start a wake-up timing operation, and when the wake-up timing ends, the TBOX controls the vehicle to power on and wake up the first controller.

[0084] In some possible implementations, the first controller may further determine the vehicle state before initiating the wake-up timing operation, so that if the vehicle state meets the requirements, the wake-up timing operation is initiated to ensure that the subsequent vehicle re-upgrade operation proceeds normally.

[0085] Exemplarily, when a controller upgrade fails during the upgrade process, the first controller determines the vehicle status. The vehicle status includes an armed state and an unarmed state. The armed state indicates that the vehicle is completely locked or the vehicle is in a security state to ensure the safety of people or objects in the vehicle. In addition, in the armed state, the "four doors and two lids" of the vehicle are all in a locked state. As shown in FIG5 , the "four doors" refer to all the doors of the vehicle, such as door 501, door 502, door 503, door 504, etc., and the "two lids" refer to the front and rear lids of the vehicle, such as the engine hood 505 and the trunk lid 506, etc. The unarmed state is the opposite of the armed state, that is, it indicates that the vehicle is in an unlocked state or the security state is released, and at least one of the "four doors and two lids" of the vehicle is in an unlocked state.

[0086] When the vehicle is in the armed state, the first controller continues to initiate the wake-up timer and controls the vehicle to power off. Since the armed state indicates the vehicle is locked, it is highly unlikely that the vehicle will start, and no user will access the vehicle's central control panel or operate vehicle components. Therefore, initiating the wake-up timer in this state and resuming the upgrade after the timer expires can reduce interruptions to the upgrade due to vehicle startup or user operations, ensuring a smooth upgrade of the entire vehicle.

[0087] If the vehicle is in the disarmed state, the first controller displays a message indicating that the vehicle upgrade has failed. For example, as shown in Figure 6 , the first controller can control the central control screen 601 displaying the HMI to display a message such as "Vehicle upgrade failed. Please wait until the vehicle is locked before upgrading again." Because the vehicle may be started or operated at any time while disarmed, the first controller will not perform another vehicle upgrade in this state, thereby reducing upgrade interruptions and improving the user experience.

[0088] In some possible implementations, the vehicle may be in the armed state and, in response to a user action, may switch to the disarmed state. When the vehicle is in the disarmed state, the ongoing vehicle upgrade operation will be forcibly terminated, and the first controller will display a message indicating that the vehicle upgrade failed. This will alert the user to the upgrade failure, allowing the user to resolve the issue themselves or seek technical assistance.

[0089] Alternatively, in some other possible implementations, after the vehicle switches from the armed state to the disarmed state, if the current wake-up timing operation has not ended, the TBOX will directly wake up the first controller, so that the first controller will also present a message to prompt that the vehicle upgrade has failed, and will not continue the vehicle upgrade operation.

[0090] In this implementation, since the vehicle state changes, it cannot be guaranteed that the whole vehicle upgrade can proceed smoothly and will not be interrupted. Therefore, the first controller terminates the whole vehicle upgrade operation.

[0091] The manner in which the first controller presents information indicating that the vehicle upgrade has failed may also refer to that shown in FIG6 , which will not be described in detail here.

[0092] In other possible implementations, the first controller can also obtain a first retry count for the upgrade operation when the vehicle is in the armed state. The first retry count indicates the number of times the upgrade operation has been re-performed on at least one controller, or the number of times the entire vehicle upgrade has been re-performed. When the first retry count is greater than zero, the first controller initiates a wake-up timer and controls vehicle power-off. Furthermore, when the first retry count is zero, the first controller displays a message indicating that the vehicle upgrade has failed.

[0093] The above-mentioned first retry number is not zero, which means that the retry number for upgrading at least one controller (or vehicle upgrade) has not been used up. In this case, the upgrade operation can be tried again to increase the probability of successful controller upgrade.

[0094] The above-mentioned first retry number is zero, which means that the retry number for upgrading at least one controller (or vehicle upgrade) has been used up. In this case, in order to avoid wasting unnecessary time by repeated retries, no retry will be performed when the retry number is used up.

[0095] S403: The first controller re-upgrades at least one controller.

[0096] In some possible implementations, after the vehicle is powered on again and awakened, the first controller may first awaken other controllers that have not been awakened, thereby further achieving the purpose of re-updating at least one controller.

[0097] Exemplarily, based on the contents of Figure 3 and S401-S403 above, the aforementioned vehicle upgrade method can also be shown in Figure 7. Among them, the failure of the first vehicle upgrade in Figure 7 indicates that there is a failure in the controller upgrade in the above embodiment, or it indicates the failure of the vehicle upgrade in Figure 3. In this case, the first controller continues to determine whether the vehicle is armed (i.e., determines the vehicle status). If the vehicle is armed (i.e., in an armed state), it continues to determine whether the number of retries is used up, and the number of retries here refers to the number of times the vehicle is upgraded (i.e., the first number of retries mentioned above). If the number of retries is not used up, the wake-up timer is started and the vehicle is controlled to power off. And, in some possible implementations, the first number of retries can also be expressed as the number of full-flow retries.

[0098] During the wake-up timing operation, if no user gets on the vehicle, the first controller waits for the wake-up timer to expire before waking up. After waking up, it re-checks the vehicle's preconditions and re-upgrades the vehicle. At the same time, the first retry count is reduced by 1. If a user gets on the vehicle during the wake-up timing operation, the vehicle's armed state is released, the wake-up timing is interrupted, and the first controller is unable to continue retrying the vehicle upgrade process, thus determining that the vehicle upgrade has failed (i.e., the second vehicle upgrade failure in Figure 7).

[0099] Furthermore, as shown in Figure 7, if the vehicle is unarmed or the first retry count has been exhausted, indicating that the vehicle upgrade has failed, or at least one controller has failed to upgrade, the first controller can terminate the upgrade without attempting to upgrade the vehicle again. Furthermore, because the first controller has already executed a software version rollback for the controller that failed to upgrade before determining whether the vehicle is armed, terminating the upgrade when the vehicle is unarmed or the first retry count has been exhausted will not affect the normal operation of the controller that failed to upgrade, and the functionality of the vehicle will not be affected.

[0100] Combining the above embodiments with the contents of FIG. 7 , it can be seen that in the vehicle upgrade method provided by the embodiments of the present application, the first controller can, in the event of a controller upgrade failure during the vehicle upgrade process, control the vehicle to power off and reset the controllers on the vehicle. When the vehicle is powered back on, the reset first controller then re-upgrades the reset controllers.

[0101] It is understandable that controllers that are in a closed or dormant state when the vehicle is powered off will be reset after the vehicle is powered on, and the communication links re-established by these controllers after the reset are generally normal. When the communication link is normal, the first controller will upgrade at least one controller again, and the probability of successful upgrade of all controllers will also increase. Alternatively, when the communication link is normal, the controller that failed to upgrade will also successfully respond to the diagnostic request, thereby improving the diagnostic success rate for the controller, and being able to more accurately analyze the cause of the upgrade anomaly based on the diagnostic results, and also improving the success rate of resolving the upgrade anomaly problem, thereby improving the success rate of re-upgrading the controller that failed to upgrade.

[0102] In addition, when the communication link is normal, the probability of the controller that failed to upgrade successfully responding to the diagnostic request will also increase, thereby improving the diagnostic success rate of other controllers or servers for the controller, and being able to more accurately analyze the cause of the upgrade abnormality based on the diagnostic results, thereby improving the success rate of resolving the upgrade abnormality problem, and thus improving the success rate of re-upgrading the controller that failed to upgrade.

[0103] From the above content, it can be seen that in the embodiment of the present application, after the entire vehicle is powered on and off, the upgrade operation of at least one controller is re-performed, which can increase the probability of successful controller upgrade, for example, the success rate can be increased by 2 to 3%, or the success rate can be increased by 0.3 to 0.8%, etc., thereby further ensuring that the functions or performance of the entire vehicle can be updated and improving the user experience.

[0104] In some schemes, multiple embodiments of the present application can be combined, and the combined scheme can be implemented. Optionally, some operations in the process of each method embodiment are optionally combined, and / or the order of some operations is optionally changed. In addition, the execution order between the steps of each process is only exemplary and does not constitute a restriction on the execution order between the steps. There can also be other execution orders between the steps. It is not intended to indicate that the execution order is the only order in which these operations can be performed. Those of ordinary skill in the art will think of many ways to reorder the operations described in the embodiments of the present application. In addition, it should be noted that the process details involved in a certain embodiment of the present application are also applicable to other embodiments in a similar manner, or different embodiments can be used in combination.

[0105] Furthermore, some steps in the method embodiments may be equivalently replaced with other possible steps. Alternatively, some steps in the method embodiments may be optional and may be deleted in certain usage scenarios. Alternatively, other possible steps may be added to the method embodiments.

[0106] Furthermore, the various method embodiments may be implemented separately or in combination.

[0107] It is understandable that in order to achieve the above functions, the aforementioned vehicle includes hardware and / or software modules corresponding to the execution of each function. In combination with the algorithm steps of each example described in the embodiments disclosed herein, the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in the form of hardware or computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application in combination with the embodiments, but such implementation should not be considered to be beyond the scope of this application.

[0108] In the embodiments of the present application, the functional modules of the vehicle can be divided according to the above-mentioned method examples. For example, each functional module can be divided according to each function, or two or more functions can be integrated into a single processing module. The above-mentioned integrated modules can be implemented in the form of hardware. It should be noted that the module division in the embodiments of the present application is schematic and is only a logical functional division. In actual implementation, other division methods may be used.

[0109] The present application also provides a vehicle that may include at least one controller described in the aforementioned embodiments, such as a first controller, a TBOX, or other controllers. The first controller may be a cockpit controller, and the other controllers may be controllers for other functional domains outside the cockpit, such as a chassis domain controller, an autonomous driving domain controller, a body domain controller, or a powertrain domain controller. The functions performed by the first controller, TBOX, and other controllers can be found in the aforementioned embodiments and will not be further elaborated here.

[0110] In some other possible embodiments, as shown in FIG8 , the vehicle provided in the embodiment of the present application may further include one or more processors 801 , memories 802 and communication interfaces 803 .

[0111] The memory 802 and the communication interface 803 are coupled to the processor 801. For example, the memory 802, the communication interface 803 and the processor 801 may be coupled together via a bus 804.

[0112] The communication interface 803 is used to transmit data with other devices. The memory 802 stores computer program code. The computer program code includes computer instructions. When the computer instructions are executed by the processor 801, the vehicle executes the vehicle upgrade method of the embodiment of the present application.

[0113] The processor 801 may be a processor or a controller, such as a central processing unit (CPU), a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It may implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the present disclosure. The processor may also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of a DSP and a microprocessor, and the like.

[0114] Bus 804 may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus. Bus 804 may be divided into an address bus, a data bus, a control bus, and the like. For ease of illustration, FIG8 shows only one thick line, but this does not imply that there is only one bus or only one type of bus.

[0115] An embodiment of the present application also provides a computer-readable storage medium, which includes computer instructions. When the computer instructions are executed on a vehicle, the vehicle can execute the relevant method steps in the above method embodiment.

[0116] An embodiment of the present application also provides a computer program product, which, when running on a vehicle, enables the vehicle to execute the relevant method steps in the above method embodiment.

[0117] Among them, the vehicle, computer storage medium or computer program product provided in this application is used to execute the corresponding method provided above. Therefore, the beneficial effects that can be achieved can refer to the beneficial effects in the corresponding method provided above, and will not be repeated here.

[0118] Through the description of the above implementation methods, technical personnel in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional modules is used as an example. In actual applications, the above-mentioned functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0119] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of the modules or units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0120] The units described as separate components may or may not be physically separate, and the components shown as units may be one physical unit or multiple physical units, that is, they may be located in one place or distributed in multiple places. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0121] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0122] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solution of the embodiment of the present application is essentially or the contributing part or all or part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for enabling a device (which can be a single-chip microcomputer, chip, etc.) or a processor to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0123] The above content is only a specific embodiment of this application, but the scope of protection of this application is not limited to this. Any changes or replacements within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

Claims

1. A method for vehicle upgrade, characterized in that, A first controller applied to a vehicle, the vehicle including at least one controller including the first controller; the method includes: Upgrading the at least one controller; When there is a situation where the upgrade of a controller fails during the upgrade process, start a wake-up timing operation and control the vehicle to power off; the wake-up timing operation is used for timing, and when the timing ends, control the vehicle to power on and wake up the first controller; Re-upgrade the at least one controller.

2. The method according to claim 1, wherein The step of, when there is a situation where the upgrade of a controller fails during the upgrade process, start a wake-up timing operation and control the vehicle to power off, includes: When there is a situation where the upgrade of a controller fails during the upgrade process, determine the vehicle state; When the vehicle is in the armed state, start a wake-up timing operation and control the vehicle to power off.

3. The method according to claim 2, wherein After determining the vehicle state when there is a situation where the upgrade of a controller fails during the upgrade process, the method further includes: When the vehicle is in the disarmed state, present information for prompting that the vehicle-wide upgrade fails.

4. The method according to claim 3, characterized in that, The method further includes: During the wake-up timing operation, if the vehicle switches from the armed state to the disarmed state, present information for prompting that the vehicle-wide upgrade fails.

5. The method according to any one of claims 2 to 4, characterized in that, The step of, when the vehicle is in the armed state, start a wake-up timing operation and control the vehicle to power off, includes: When the vehicle is in the armed state, obtain the first retry count of the upgrade operation; When the first retry count is greater than zero, start a wake-up timing operation and control the vehicle to power off; the first retry count represents the number of times of re-upgrading the at least one controller for the upgrade operation.

6. The method according to claim 5, wherein The method further includes: When the first retry count is zero, present information for prompting that the vehicle-wide upgrade fails.

7. The method according to any one of claims 1 to 6, characterized in that, The step of upgrading the at least one controller includes: When the vehicle meets a first preset condition, based on the obtained upgrade software package for the vehicle-wide upgrade, upgrade the at least one controller respectively; the first preset condition includes one or more of the vehicle being in a stationary state, the vehicle not being started, and the gear of the vehicle being in a preset gear; When the at least one controller is upgraded successfully respectively, present information for prompting that the vehicle-wide upgrade is successful.

8. The method according to claim 7, wherein The step of, based on the obtained upgrade software package for the vehicle-wide upgrade, upgrade the at least one controller respectively, includes: When upgrading one controller, When the upgrade of the controller fails and the vehicle meets a second preset condition, obtain the second retry count of the upgrade operation for the controller; the second preset condition includes the vehicle being in a state where it cannot be started and / or the vehicle being in a state where the doors cannot be opened; When the second retry count is greater than zero, re-upgrade the controller; When the second retry count is equal to zero, determine that the upgrade of the controller fails.

9. A vehicle, characterized in that, The vehicle includes at least one controller including the first controller; The first controller is used to upgrade the at least one controller; when there is a situation where the upgrade of a controller fails during the upgrade process, it controls the remote communication controller to start a wake-up timing operation and controls the vehicle to power off; the wake-up timing operation is used for timing, and when the timing ends, it controls the vehicle to power on and wakes up the first controller; The first controller is further used to re-upgrade the at least one controller.

10. A vehicle, characterized in that, It includes a memory and one or more controllers; the memory is coupled to the controller; wherein, computer program code is stored in the memory, and the computer program code includes computer instructions, when the computer instructions are executed by the controller, the vehicle is caused to execute the vehicle upgrade method described in any one of claims 1-8.

11. A computer-readable storage medium, characterized in that, It includes computer instructions, when the computer instructions run on the vehicle, the vehicle is caused to execute the vehicle upgrade method described in any one of claims 1-8.

Images