Upgrading method and device and vehicle

Abstract

The invention discloses an upgrading method and device and a vehicle, and relates to the technical field of equipment upgrading. The method comprises the steps that a first device obtains a first upgrading task; when the first equipment meets a first upgrading condition, first OTA upgrading is carried out on the first component according to a first upgrading package in the first upgrading task, and the first upgrading condition at least comprises a condition associated with the first component; when the first OTA upgrade fails, the first device determines whether the first device meets a second upgrade condition, the second upgrade condition does not comprise a condition associated with the first component and / or a second component, and the second component is a component causing the first OTA upgrade failure; and when the first equipment meets the second upgrading condition, the first equipment performs second OTA upgrading on the first component according to the second upgrading package. According to the method, the efficiency of repairing the first equipment and the use experience of a user can be improved.

Description

Upgrading method, device and vehicle Technical Field

[0001] The present application relates to the technical field of equipment upgrades, and in particular to an upgrade method, device, and vehicle. Background Art

[0002] With the development of vehicle intelligent networking technology and over the air (OTA) technology, more and more vehicles support online upgrades of vehicle components using OTA technology (hereinafter referred to as OTA upgrades). Specifically, the vehicle's OTA system can download the upgrade package corresponding to the component through the OTA server, and then flash the data of the component according to the upgrade package to achieve the upgrade of the component. Before the vehicle performs an OTA upgrade, the vehicle's OTA system needs to detect whether the core components of the vehicle upgrade (such as: battery, network control unit (telematics box, T-Box)) are functioning normally, and whether the vehicle meets the upgrade conditions for OTA upgrade.

[0003] During the vehicle's OTA upgrade process, if a core component experiences an abnormality (e.g., battery failure, T-Box restart), the data flashing of the component to be upgraded will be interrupted or the upper-layer application of the component to be upgraded will be damaged, causing the system function of the component to be upgraded to be damaged and unable to be used normally, resulting in the failure of the vehicle's OTA upgrade. Moreover, even if the core component returns to normal, the vehicle's OTA system will not be able to accurately detect whether the vehicle still meets the upgrade conditions for the OTA upgrade due to the damage to the system function of the component to be upgraded and its inability to be used normally, and thus will be unable to continue the vehicle's OTA upgrade to repair the vehicle that failed the OTA upgrade.

[0004] In related technologies, if a vehicle's OTA upgrade fails and cannot be repaired, OTA upgrade operators must arrive at the vehicle site to provide technical support, or the user must tow the vehicle to an OTA upgrade service shop for repair or component replacement to repair the failed OTA upgrade and restore normal vehicle functionality. This consumes a lot of time and manpower, and does not allow for quick and convenient repair of vehicles that have failed OTA upgrades.

[0005] Summary of the Invention

[0006] The present application provides an upgrade method, apparatus, and vehicle that, when a first OTA upgrade of a first component in a first device (e.g., a vehicle) fails according to a first upgrade condition, can perform a second OTA upgrade (or repair upgrade) on the first component according to a second upgrade condition. The second upgrade condition does not include conditions associated with the first component and / or the component that caused the failure of the first OTA upgrade. In this way, the first component of the first device can be repaired and upgraded quickly and conveniently.

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

[0008] In a first aspect, an upgrade method is provided, the method comprising: a first device obtains a first upgrade task, wherein the first upgrade task includes a first upgrade package, and the first upgrade package is used for an over-the-air OTA upgrade of a first component of the first device. When the first device meets a first upgrade condition, the first device performs a first OTA upgrade on the first component according to the first upgrade package, wherein the first upgrade condition at least includes a condition associated with the first component. When the first OTA upgrade fails, the first device determines whether the first device meets a second upgrade condition, the second upgrade condition does not include a condition associated with the first component and / or the second component, and the second component is the component that caused the failure of the first OTA upgrade. When the first device meets the second upgrade condition, the first device performs a second OTA upgrade on the first component according to the second upgrade package, wherein the second upgrade package is associated with the first upgrade package.

[0009] In this method, after a first device fails to perform a first OTA upgrade on a first component, a second OTA upgrade can be performed on the first component according to a second upgrade condition. That is, the first device can perform a second OTA upgrade on the first component in situations such as when the first component and / or the second component is damaged or when the detection results of the first component and / or the second component cannot be obtained. This allows the first component of the first device to be repaired and upgraded quickly, improving the efficiency of repairing the first component and the user experience.

[0010] In combination with the first aspect, in an optional implementation, after the first OTA upgrade fails and before the second OTA upgrade, the method also includes at least one of the following: the first device does not perform detection on the first component, the first device does not perform detection on the second component, the first device performs detection on the first component and ignores the detection result obtained by detecting the first component, and the first device performs detection on the second component and ignores the detection result obtained by detecting the second component.

[0011] In this implementation, since the second upgrade condition does not include conditions associated with the first component and / or the second component, when the first device performs the detection step before the second OTA upgrade, the first device may not perform detection on the first component and / or the second component, or may perform detection on the first component and / or the second component but ignore the detection results. This allows for rapid determination of whether the first device meets the second upgrade condition, thereby improving the efficiency of the second OTA upgrade of the first component.

[0012] In conjunction with the first aspect, in an optional implementation, after the first OTA upgrade of the first device fails, the method further includes: the first device obtaining first indication information, where the first indication information is used to instruct the execution of a second OTA upgrade according to a second upgrade condition. In this implementation, after obtaining the first indication information, the first device can respond to the first indication information and execute the second OTA upgrade according to the second upgrade condition. In this way, the efficiency of the second OTA upgrade of the first component by the first device can be guaranteed.

[0013] In conjunction with the first aspect, in one optional implementation, the second upgrade condition is determined based on status information of the first component and / or the second component, where the status information of the first component and / or the second component is associated with the failure of the first OTA upgrade. In this way, the second upgrade condition can be accurately determined, enabling the first device to perform a second OTA upgrade on the first component and thereby repair the first component if the second upgrade condition is met.

[0014] In conjunction with the first aspect, in an optional implementation, after the first OTA upgrade fails and before the second OTA upgrade, the method further includes: the first device waking up a third component, where the third component includes at least a component associated with the second OTA upgrade of the first component. In this implementation, the first device may also wake up the component associated with the second OTA upgrade of the first component before the second OTA upgrade. This eliminates the need to wake up the entire first device, further reducing the power consumption of the first device.

[0015] In conjunction with the first aspect, in an optional implementation, waking up the third component on the first device includes: the first device receiving a wake-up instruction, the wake-up instruction being used to wake up the third component. The first device awakens the third component in response to the wake-up instruction. In this implementation, if the first device is unable to wake up the third component due to a failure of a first OTA upgrade of the first component, the first device can receive a wake-up instruction sent by the OTA server and awaken the third component in response to the wake-up instruction. This can improve the success rate of waking up the third component on the first device.

[0016] In conjunction with the first aspect, in an optional implementation, the wake-up instruction is determined based on the status information of the third component. In this way, the wake-up instruction can be accurately determined to further improve the success rate of waking up the third component.

[0017] In conjunction with the first aspect, in one optional implementation, the upgrade type corresponding to the second OTA upgrade is a forced upgrade. In this implementation, if the second upgrade condition is met, the first device can force the second OTA upgrade of the first component without user authorization. This ensures that the first device can perform the second OTA upgrade of the first component according to the second upgrade condition, thereby improving the success rate of the second OTA upgrade of the first component.

[0018] In a second aspect, an upgrade method is provided, comprising: an OTA server sending a first upgrade task, the first upgrade task including a first upgrade package, the first upgrade package being used to perform an OTA upgrade on a first component of a first device. If the first device fails to perform a first OTA upgrade of the first component according to the first upgrade package, the OTA server sending first indication information, wherein the first indication information is used to instruct the first device to perform a second OTA upgrade according to a second upgrade condition, the second upgrade condition not including a condition associated with the first component and / or a second component, the second component being the component that caused the first OTA upgrade to fail, the second OTA upgrade being an upgrade of the first component according to the second upgrade package, and the second upgrade package being associated with the first upgrade package.

[0019] In this method, the OTA server can send first instruction information to the first device, instructing the first device to perform a second OTA upgrade based on a second upgrade condition, where the second upgrade condition does not include conditions associated with the first component and / or the second component. In this way, the first device can perform a second OTA upgrade on the first component to repair the first component if the second upgrade condition is met.

[0020] In combination with the second aspect, in an optional implementation, the first device performs a second OTA upgrade according to a second upgrade condition, including at least one of the following: the first device does not perform detection on the first component, the first device does not perform detection on the second component, the first device performs detection on the first component and ignores the detection result obtained by detecting the first component, and the first device performs detection on the second component and ignores the detection result obtained by detecting the second component.

[0021] In conjunction with the second aspect, in an optional implementation, before sending the first indication information, the method further includes: the OTA server obtaining status information of the first component and / or status information of the second component, where the status information of the first component and / or the status information of the second component is associated with the failure of the first OTA upgrade. The OTA server determines a second upgrade condition based on the status information of the first component and / or the second component.

[0022] In conjunction with the second aspect, in an optional implementation, the OTA server obtaining status information of the first component and / or the second component includes: the OTA server receiving one or more items of log information and user feedback information of the first OTA upgrade. The OTA server determines the status information of the first component and / or the second component based on the one or more items of the log information and the user feedback information.

[0023] In conjunction with the second aspect, in an optional implementation, after the first OTA upgrade fails and before the second OTA upgrade, the method further includes: the OTA server sending a wake-up instruction, the wake-up instruction being used to wake up a third component, wherein the third component includes at least a component associated with the first component during the second OTA upgrade.

[0024] In conjunction with the second aspect, in an optional implementation, before the OTA server sends the wake-up instruction, the method further includes: the OTA server obtaining status information of the third component, and determining the wake-up instruction based on the status information of the third component.

[0025] In combination with the second aspect, in an optional implementation method, the OTA server obtains the status information of the third component, including: the OTA server receives one or more items of log information and user feedback information of the first OTA upgrade; the OTA server determines the status information of the third component based on one or more items of log information and user feedback information.

[0026] In conjunction with the second aspect, in an optional implementation, the upgrade type corresponding to the second OTA upgrade is a forced upgrade.

[0027] According to a third aspect, an upgrade method is provided, which includes: a first device sends a first prompt message, and the first indication message is used to inquire whether the user using the first device accepts the second upgrade condition. The second upgrade condition is the condition for the second OTA upgrade, the second OTA upgrade is the upgrade after the failure of the first OTA upgrade, and the first OTA upgrade is the upgrade of the first component of the first device according to the first upgrade package when the first device meets the first upgrade condition. The first upgrade condition at least includes the condition associated with the first component, and the second upgrade condition does not include the condition associated with the first component and / or the second component. The second component is the component that caused the failure of the first OTA upgrade. The first device receives a first response message from the user, and the first response message is used to indicate whether the user accepts the second upgrade condition. If the user accepts the second upgrade condition, the first device performs a second OTA upgrade on the first component according to the second upgrade condition after the failure of the first OTA upgrade.

[0028] In this method, the first device can send a first prompt message to inquire whether the user of the first device accepts the second upgrade condition. In this way, the security of the first device performing the second OTA upgrade on the first component according to the second upgrade condition can be improved.

[0029] In conjunction with the third aspect, in an optional implementation, after the first OTA upgrade fails, the method further includes: the first device sending a second prompt message, the second prompt message being used to inquire whether the user accepts the second OTA upgrade of the first component according to the second upgrade condition. The first device receives a second response message from the user, the second response message being used to indicate whether the user accepts the second OTA upgrade of the first component according to the second upgrade condition. If the user accepts the second OTA upgrade of the first component according to the second upgrade condition, the first device performs the second OTA upgrade on the first component according to the second upgrade condition.

[0030] In this implementation, after the first OTA upgrade fails, the first device can also send a second prompt message to ask the user whether to accept the second OTA upgrade of the first component based on the second upgrade conditions. This can further improve the security of the first device performing the second OTA upgrade of the first component.

[0031] In combination with the third aspect, in an optional implementation, after the first OTA upgrade fails, the method further includes: the first device obtains the location information of the first device. The first device sends a second prompt message when the first distance is greater than the first threshold, and the second prompt message is used to ask the user whether to accept the second OTA upgrade of the first component according to the second upgrade condition. The first distance is associated with the location information, and the first distance is the distance between the first device and the OTA upgrade center. The OTA upgrade center is used to perform the second OTA upgrade on the first component. The first device receives a second response message from the user, and the second response message is used to indicate whether the user accepts the second OTA upgrade of the first component according to the second upgrade condition. If the user accepts the second OTA upgrade of the first component according to the second upgrade condition, the first device performs a second OTA upgrade on the first component according to the second upgrade condition.

[0032] In this implementation, the first device can determine whether to send the second prompt based on the first device's location information and the distance between the first device and the OTA upgrade center. The second prompt is sent if the distance between the first device and the OTA upgrade center is greater than a first threshold. This improves the effectiveness of the second prompt, thereby increasing the efficiency of the second OTA upgrade for the first component.

[0033] In combination with the third aspect, in an optional implementation, after the first OTA upgrade fails, the method further includes: the first device obtains first indication information, where the first indication information is used to indicate that a second OTA upgrade is to be performed according to a second upgrade condition.

[0034] In combination with the third aspect, in an optional implementation method, the first device performs a second OTA upgrade on the first component according to a second upgrade condition, including: when the first device meets the second upgrade condition, the first device performs a second OTA upgrade on the first component according to a second upgrade package, wherein the second upgrade package is associated with the first upgrade package.

[0035] In a fourth aspect, an upgrade method is provided, the method comprising: a first device receiving and displaying a first prompt message, the first indication message being used to inquire whether a user using the first device accepts a second upgrade condition, the second upgrade condition being a condition for a second OTA upgrade, the second OTA upgrade being an upgrade after the failure of the first OTA upgrade, the first OTA upgrade being an upgrade of a first component of the first device according to a first upgrade package when the first device satisfies the first upgrade condition, the first upgrade condition at least including a condition associated with the first component, the second upgrade condition not including a condition associated with the first component and / or the second component, the second component being the component that caused the failure of the first OTA upgrade. The first device receives a first response message from the user, the first response message being used to indicate whether the user accepts the second upgrade condition. If the user accepts the second upgrade condition, the first device performs a second OTA upgrade on the first component according to the second upgrade condition after the failure of the first OTA upgrade.

[0036] In conjunction with the fourth aspect, in an optional implementation, after the first OTA upgrade fails, the method further includes: the first device receiving and displaying a second prompt message, the second prompt message being used to inquire whether the user accepts the second OTA upgrade of the first component according to the second upgrade condition. The first device receives a second response message from the user, the second response message being used to indicate whether the user accepts the second OTA upgrade of the first component according to the second upgrade condition. If the user accepts the second OTA upgrade of the first component according to the second upgrade condition, the first device performs the second OTA upgrade on the first component according to the second upgrade condition.

[0037] In combination with the fourth aspect, in an optional implementation, after the first OTA upgrade fails, the method further includes: the first device obtains the location information of the first device. When the first distance is greater than the first threshold, the first device receives and displays a second prompt message, and the second prompt message is used to ask the user whether to accept the second OTA upgrade of the first component according to the second upgrade condition. The first distance is associated with the location information, and the first distance is the distance between the first device and the OTA upgrade center. The OTA upgrade center is used to perform the second OTA upgrade on the first component. The first device receives a second response message from the user, and the second response message is used to indicate whether the user accepts the second OTA upgrade of the first component according to the second upgrade condition. If the user accepts the second OTA upgrade of the first component according to the second upgrade condition, the first device performs a second OTA upgrade on the first component according to the second upgrade condition.

[0038] In a fifth aspect, an upgrade method is provided, the method comprising: an OTA server sending a first prompt message, the first indication message being used to inquire whether a user using a first device accepts a second upgrade condition, the second upgrade condition being a condition for a second OTA upgrade, the second OTA upgrade being an upgrade after a failure of the first OTA upgrade, the first OTA upgrade being an upgrade of a first component of the first device according to a first upgrade package when the first device satisfies the first upgrade condition, the first upgrade condition including at least a condition associated with the first component, the second upgrade condition not including a condition associated with the first component and / or the second component, the second component being the component that caused the failure of the first OTA upgrade. If the user accepts the second upgrade condition, the OTA server sends a first indication message after the failure of the first OTA upgrade, wherein the first indication message is used to instruct the first device to perform a second OTA upgrade according to the second upgrade condition.

[0039] In combination with the fifth aspect, in an optional implementation, after the first OTA upgrade fails and before sending the first indication information, the method also includes: the OTA server sends a second prompt message, and the second prompt message is used to ask the user whether to accept the second OTA upgrade of the first component according to the second upgrade condition.

[0040] In a sixth aspect, an upgrade device is provided, which includes: an acquisition module and a processing module. The acquisition module is used to acquire a first upgrade task, the first upgrade task includes a first upgrade package, and the first upgrade package is used for an over-the-air OTA upgrade of a first component of a first device. The processing module is used to perform a first OTA upgrade on the first component according to the first upgrade package when the first device meets the first upgrade condition, wherein the first upgrade condition at least includes a condition associated with the first component. The processing module is also used to determine whether the first device meets the second upgrade condition when the first OTA upgrade fails, the second upgrade condition does not include a condition associated with the first component and / or the second component, and the second component is the component that caused the failure of the first OTA upgrade. The processing module is also used to perform a second OTA upgrade on the first component according to the second upgrade package when the first device meets the second upgrade condition, wherein the second upgrade package is associated with the first upgrade package.

[0041] In combination with the sixth aspect, in an optional implementation method, after the first OTA upgrade fails and before the second OTA upgrade, the processing module is specifically used to perform at least one of the following: not performing detection on the first component, not performing detection on the second component, performing detection on the first component and ignoring the detection result obtained by detecting the first component, performing detection on the second component and ignoring the detection result obtained by detecting the second component.

[0042] In combination with the sixth aspect, in an optional implementation, after the first OTA upgrade fails, the acquisition module is further used to obtain first indication information, where the first indication information is used to indicate that a second OTA upgrade is to be performed according to a second upgrade condition.

[0043] In combination with the sixth aspect, in an optional implementation, after the first OTA upgrade fails and before the second OTA upgrade, the processing module is also used to wake up the third component, wherein the third component includes at least a component associated with the second OTA upgrade of the first component.

[0044] In conjunction with the sixth aspect, in an optional implementation, the acquiring module is further configured to receive a wake-up instruction, and the processing module is further configured to wake up the third component in response to the wake-up instruction.

[0045] In a seventh aspect, an upgrade device is provided, which includes: a sending module. Specifically, the sending module is used to send a first upgrade task, the first upgrade task includes a first upgrade package, and the first upgrade package is used to perform an OTA upgrade on a first component of a first device. The sending module is also used to send a first indication message when the first device fails to perform a first OTA upgrade on the first component according to the first upgrade package, wherein the first indication message is used to instruct the first device to perform a second OTA upgrade according to a second upgrade condition, the second upgrade condition does not include a condition associated with the first component and / or the second component, the second component is the component that caused the failure of the first OTA upgrade, the second OTA upgrade is to upgrade the first component according to the second upgrade package, and the second upgrade package is associated with the first upgrade package.

[0046] In conjunction with the seventh aspect, in an optional implementation, the apparatus further includes: an acquisition module and a processing module. The acquisition module is configured to acquire status information of the first component and / or status information of the second component, where the status information of the first component and / or the status information of the second component is associated with the failure of the first OTA upgrade. The processing module is configured to determine a second upgrade condition based on the status information of the first component and / or the second component.

[0047] In conjunction with the seventh aspect, in an optional implementation, the acquiring module is further configured to acquire status information of the third component. The processing module is further configured to determine a wake-up instruction based on the status information of the third component. The sending module is further configured to send the wake-up instruction.

[0048] In an eighth aspect, a vehicle is provided, comprising: an upgrading device for executing the method as described in the first aspect and any one of its optional methods, or the upgrading device for executing the method as described in the third aspect and any one of its optional methods, or the upgrading device for executing the method as described in the fourth aspect and any one of its optional methods.

[0049] In the ninth aspect, an electronic device is provided, comprising: a memory, one or more processors; the memory is coupled to the processor; wherein computer program code is stored in the memory, and the computer program code includes computer instructions, and when the computer instructions are executed by the processor, the electronic device executes the method as described in the first aspect and any one of its optional methods, or the electronic device executes the method as described in the second aspect and any one of its optional methods, or the electronic device executes the method as described in the third aspect and any one of its optional methods, or the electronic device executes the method as described in the fourth aspect and any one of its optional methods, or the electronic device executes the method as described in the fifth aspect and any one of its optional methods.

[0050] In the tenth aspect, a computer-readable storage medium is provided, comprising computer instructions. When the computer instructions are executed on an electronic device, the electronic device executes the method according to the first aspect and any one of its optional methods, or the electronic device executes the method according to the second aspect and any one of its optional methods, or the electronic device executes the method according to the third aspect and any one of its optional methods, or the electronic device executes the method according to the fourth aspect and any one of its optional methods, or the electronic device executes the method according to the fifth aspect and any one of its optional methods.

[0051] In the eleventh aspect, a computer program product is provided. When the computer program product is run on a computer, it enables the computer to execute the method as described in the first aspect and any one of its optional methods, or enables the computer to execute the method as described in the second aspect and any one of its optional methods, or enables the computer to execute the method as described in the third aspect and any one of its optional methods, or enables the computer to execute the method as described in the fourth aspect and any one of its optional methods, or enables the computer to execute the method as described in the fifth aspect and any one of its optional methods.

[0052] It can be understood that the beneficial effects that can be achieved by the upgrade methods of the third to fifth aspects, the upgrade device of the sixth aspect, the upgrade device of the seventh aspect, the vehicle of the eighth aspect, the electronic device of the ninth aspect, the computer-readable storage medium of the tenth aspect, and the computer program product of the eleventh aspect can be referred to the beneficial effects of the first aspect and any possible design method thereof, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0053] FIG1 is a schematic diagram of a vehicle OTA upgrade failure provided by related art;

[0054] FIG2 is a schematic diagram of an application scenario provided by an embodiment of the present application;

[0055] FIG3 is a schematic diagram of an architecture of an application scenario provided in an embodiment of the present application;

[0056] FIG4 is a schematic diagram of a vehicle functional system upgrade failure according to an embodiment of the present application;

[0057] FIG5 is a flowchart of an upgrade method according to an embodiment of the present application;

[0058] FIG6 is a first schematic diagram of an OTA server creating a second upgrade task according to an embodiment of the present application;

[0059] FIG7 is a second schematic diagram of an OTA server creating a second upgrade task according to an embodiment of the present application;

[0060] FIG8 is a schematic diagram of a flow chart of a second OTA upgrade method provided in an embodiment of the present application;

[0061] FIG9 is a schematic diagram of a scenario for waking up a third component according to an embodiment of the present application;

[0062] FIG10 is a second flow chart of an upgrade method provided in an embodiment of the present application;

[0063] FIG11 is a schematic diagram 1 showing a first prompt message according to an embodiment of the present application;

[0064] FIG12 is a second schematic diagram of displaying a first prompt message provided by an embodiment of the present application;

[0065] FIG13 is a first schematic diagram of displaying a second prompt message according to an embodiment of the present application;

[0066] FIG14 is a second schematic diagram of displaying a second prompt message provided by an embodiment of the present application;

[0067] FIG15 is a third flow chart of an upgrade method provided in an embodiment of the present application;

[0068] FIG16 is a fourth flow chart of an upgrade method provided in an embodiment of the present application;

[0069] FIG17 is a first structural diagram of an upgrading device provided in an embodiment of the present application;

[0070] FIG18 is a second structural diagram of an upgrading device provided in an embodiment of the present application;

[0071] FIG19 is a schematic diagram showing the composition of a chip system according to an embodiment of the present application. DETAILED DESCRIPTION

[0072] In the description of this application, unless otherwise specified, " / " indicates that the objects associated with each other are in an "or" relationship. For example, A / B can represent A or B. "And / or" in this application is only a description of the association relationship of associated objects, indicating that three relationships can exist. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone. A and B can be singular or plural. In addition, in the description of this application, unless otherwise specified, "multiple" means 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, and 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 basically 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. Specifically, the use of words such as "exemplary" or "for example" is intended to present related concepts in a concrete way for easy understanding.

[0073] With the development of vehicle intelligent networking technology and over-the-air (OTA) technology, more and more vehicles support the use of OTA technology to download upgrade packages from OTA servers to perform online upgrades on components in the vehicle through the upgrade packages. For example, OTA technology can be used to upgrade the vehicle's battery management system (BMS), motor control unit (MCU), and battery management system (BMS) and other electronic control units (ECU). In this way, the vehicle can be upgraded through OTA to improve the efficiency of vehicle upgrades and user experience, saving upgrade costs.

[0074] However, every time the vehicle is undergoing an OTA upgrade (including the first time the OTA upgrade is started, and the subsequent upgrade started after the OTA upgrade is abnormally recovered), in order to ensure the safety of the vehicle's OTA upgrade, the vehicle's OTA system needs to ensure that the core components of the vehicle upgrade (such as the battery, the telematics box (T-Box) or the vehicle control unit (VCU), etc.) are functioning normally. For example: ensure that the battery's power supply function, sleep wake-up function, and power-on (or high voltage, i.e., output power voltage) function are normal, and ensure that the T-Box's networking function and communication function are normal. In addition, the vehicle's OTA system also needs to detect whether the vehicle meets the upgrade conditions for the OTA upgrade to ensure that the vehicle is upgraded OTA when the upgrade conditions for the OTA upgrade are met.

[0075] During the OTA upgrade process of the vehicle, if a core component malfunctions (for example, a battery failure or a T-Box restart), the data flashing of the system of the component to be upgraded will be interrupted or the upper-layer application of the component to be upgraded will be damaged, causing the system function of the component to be upgraded to be damaged and unable to be used normally. Moreover, even if the core component returns to normal, the system function of the component to be upgraded will be damaged and unable to be used normally. The vehicle's OTA system cannot determine whether the component to be upgraded meets the upgrade conditions, that is, the vehicle's OTA system cannot accurately detect whether the vehicle still meets the upgrade conditions for the OTA upgrade, which in turn makes it impossible to perform the vehicle's OTA upgrade (repair upgrade) again to repair the vehicle that failed the OTA upgrade.

[0076] For example, please refer to FIG1 , which is a schematic diagram of an application scenario of a vehicle OTA upgrade failure provided by the related art.

[0077] As shown in Scenario 1 in Figure 1, take the OTA upgrade of the vehicle's BMS, PDU, or MCU as an example. If a battery failure occurs during the process of flashing data to the BMS, PDU, or MCU, the data flashing process will be interrupted, resulting in damage to the upper-layer applications of the BMS, PDU, or MCU. Even after the battery is restored, the BMS, PDU, or MCU system function is damaged and cannot be used normally, resulting in the main control program module (e.g., OTA Manger) in the vehicle's OTA system failing to request the wake-up voltage (or KL15 voltage) and power voltage (or upper high voltage). Since the multi-domain controller (MDC) requires a high-voltage state to start (i.e., it needs to be in a power voltage state), the MDC cannot start receiving the Ethernet message from the OTA Manger to enter the upgrade mode, causing the OTA Manger to enter the failure process according to the upgrade mode and the vehicle OTA upgrade to fail.

[0078] As shown in Scenario 2 and Scenario 3 in Figure 1, take the OTA upgrade of the vehicle's passive entry passive start (PEPS) system as an example. During the process of the vehicle flashing data to the PEPS system, if a battery failure occurs or the T-Box restarts, the data flashing will be interrupted, resulting in damage to the upper-layer applications of the PEPS system. Even after the battery is restored or the T-Box is restarted, the T-Box needs to re-power KL15 through the PEPS system, but because the upper-layer applications of the PEPS system are damaged, KL15 cannot be powered normally. Therefore, the T-Box cannot be used normally and the vehicle OTA upgrade fails.

[0079] In the related art, when a vehicle OTA upgrade fails, resulting in damage to the system functions of the upgraded components and inability to use them normally, OTA upgrade operation service personnel are usually required to arrive at the vehicle site to provide technical support (such as professional problem troubleshooting and vehicle repair), or the user (for example, through the manufacturer) tows the vehicle to a service shop that provides OTA upgrades (such as a vehicle after-sales service station or the vehicle's corresponding authorized repair point) for repair or replacement of parts to repair the vehicle that failed the OTA upgrade and restore the vehicle to normal use. This consumes a lot of time and manpower costs, and it is impossible to quickly and conveniently repair the vehicle that failed the OTA upgrade.

[0080] In order to solve the above problems, an embodiment of the present application provides an upgrade method. Using the method provided by this embodiment, when the first device (for example, the above-mentioned vehicle) fails to perform the first OTA upgrade on the first component according to the first upgrade condition, it can determine whether the first device meets the second upgrade condition. When the first device meets the second upgrade condition, a second OTA upgrade is performed on the first component to repair the first device. The second upgrade condition does not include conditions associated with the first component and / or the second component, and the second component is the component that caused the failure of the first OTA upgrade. In this way, the first device can perform a second OTA upgrade (i.e., a repair upgrade) on the first component of the first device when the first component and / or the second component is damaged, or the detection results of the first component and / or the second component cannot be obtained, so that the first device that failed the OTA upgrade can be quickly repaired, thereby improving the efficiency of repairing the first device and the user experience.

[0081] For example, assuming the first device is a vehicle and the first component is a PEPS in the vehicle, upgrading the PEPS using the method provided in an embodiment of the present application may include: first, the vehicle obtains a first upgrade task, the first upgrade task including a first upgrade package for performing an OTA upgrade on the PEPS, and the first upgrade package including OTA upgrade data for flashing data on the PEPS.

[0082] Then, if the vehicle meets first upgrade conditions, a first OTA upgrade is performed on the PEPS based on the first upgrade package. The first upgrade conditions may include conditions related to the PEPS, such as: PEPS upgrade authorization is enabled, PEPS is pulled up, and the KL15 power supply is normal. The first upgrade conditions may also include conditions related to the OTA system and vehicle safety, such as: the PEPS upgrade package is in place, the PEPS upgrade package has passed verification, the vehicle is in upgrade mode, the vehicle is in Park (P), the ACC is in OFF, the high-voltage battery is not charged, and the battery charge meets the upgrade requirements.

[0083] If a vehicle fails a first OTA upgrade of the PEPS (Peripheral Electronics Processing) (PEPS), for example, due to a battery failure, the vehicle can determine whether it meets second upgrade conditions. These second upgrade conditions do not include conditions related to the PEPS and / or the component that caused the failure (e.g., the battery) (e.g., PEPS upgrade authorization status, PEPS KL15 power status is normal, battery charge meets upgrade requirements, etc.). Therefore, the second upgrade conditions may include: the upgrade package is available, the upgrade package has passed verification, the vehicle is in upgrade mode, the vehicle is in Park (P), and the ACC gear is in OFF.

[0084] Finally, if the vehicle meets the second upgrade condition, the vehicle performs a second OTA upgrade of the PEPS using the second upgrade package. The second upgrade package is associated with the first upgrade package. This allows the vehicle to repair the PEPS by performing a second OTA upgrade based on the second upgrade condition if the first OTA upgrade fails.

[0085] The following describes the solution provided by the embodiments of the present application in conjunction with the accompanying drawings.

[0086] The upgrade method provided in the embodiments of the present application can be applied to scenarios where electronic devices such as the first device mentioned above are undergoing OTA upgrades. Below, the upgrade method provided in the embodiments of the present application is described using the first device as a vehicle. The vehicles in the embodiments of the present application can be: smart cars, trucks, motorcycles, buses, lawn mowers, recreational vehicles, amusement park vehicles, construction equipment, trams, golf carts, and carts, etc. The embodiments of the present application do not impose any restrictions on the specific types of vehicles.

[0087] Specifically, referring to FIG2 , which is a schematic diagram of an application scenario provided by an embodiment of the present application, as shown in FIG2 , taking the application scenario of OTA upgrade of a vehicle as an example, the application scenario includes: a vehicle 100 and an OTA server 200. The vehicle 100 includes an in-vehicle system 110 and an OTA system 120. The OTA system 120 can be used to obtain upgrade tasks and upgrade components in the in-vehicle system 110 according to the upgrade tasks.

[0088] The OTA server 200 may be, for example, an OTA management platform. The OTA server 200 may be used to create upgrade tasks, determine upgrade packages, and determine upgrade conditions, and may send upgrade tasks, upgrade packages, and upgrade conditions to the vehicle 100 .

[0089] The vehicle 100 and the OTA server 200 can establish a communication connection via the vehicle-to-cloud channel 300 to establish a networked communication link for implementing OTA functions. The vehicle-to-cloud channel 300 may include, for example, a command channel for OTA task information and a data transmission channel for downloading upgrade packages.

[0090] Referring to FIG3 , which is a schematic diagram of the architecture of an application scenario provided in an embodiment of the present application, FIG3 shows the components included in the vehicle system 110. The vehicle system 110 may include a T-Box 111, a gateway (or vehicle gateway) 112, an on-board diagnostics (OBD) 113, an ECU 114, an in-vehicle infotainment (IVI) system 115, and an intrusion detection system (IDS) 116. The components within the vehicle system 110 can be interconnected via a controller area network (CAN) bus. The ECU 114 can be a control unit with different functions, such as a cockpit domain controller (CDC), an inertial measurement unit (IMU), a mobile data center (MDC), a VCU, etc.

[0091] The T-Box 111 may be capable of communicating with external devices of the vehicle 100 as well as internal devices of the vehicle 100. The external devices of the vehicle 100 may be described as devices outside the vehicle 100.

[0092] The gateway 112 is a core component of the vehicle 100 , and the gateway 112 can route message data on the CAN bus among different networks.

[0093] The OBD 113 may be capable of monitoring the operating status of the vehicle and generating a fault code when a problem occurs with the vehicle.

[0094] The ECU 114 may be a microcomputer controller of the vehicle 100 and may be capable of executing preset control functions, for example, it may be used to control engine operation, protect vehicle safety, etc.

[0095] The IVI system 115 may be an infotainment system of the vehicle 100 .

[0096] The IDS 116 can be capable of diagnosing vehicle faults, such as detecting whether message data transmitted on the CAN bus is abnormal, etc. The IDS 116 can be deployed in vehicle components, such as the T-box 111, gateway 112, MDC, CDC, or VCU.

[0097] It should be understood that the architecture of the vehicle-mounted system 110 shown in FIG3 is for illustrative purposes only and is not intended to limit the technical solutions of this application. Those skilled in the art will appreciate that, in a specific implementation, the vehicle-mounted system 110 may also include other devices, and the number of gateways and ECUs may also be determined based on specific needs.

[0098] In some implementations, each component of the in-vehicle system 110 in FIG. 3 of the embodiment of the present application, such as the T-Box 111, the gateway 112, the ECU 114, or the IDS 116, can be a physical device or a functional module within a physical device or device. The functional module can be a component in a hardware device, a software function running on dedicated hardware, or a virtualized function instantiated on a platform (e.g., a cloud platform).

[0099] 3 , the OTA system 120 in the vehicle 100 may include an OTA main control module 121 , an update agent (UA) module 122 , and a vehicle function system 123 .

[0100] Among them, the OTA main control module 121 can also be called OTA Manager. OTA Manager is the main control module in the OTA system, responsible for coordinating the OTA upgrade strategy and upgrade process control of the vehicle 100.

[0101] The UA module 122 is responsible for downloading and / or installing the upgrade package. It can be used to receive the scheduling of the OTA main control module 121 and flash the data of the ECU electronic control unit that needs to be upgraded to perform OTA upgrade.

[0102] The vehicle function system 123 may include, for example, an energy management system, a vehicle mode management system, and a power system. The vehicle function system 123 may also include the systems in the aforementioned vehicle system 110, such as the OBD 113 and the IDS 116. The vehicle function system 123 is an OTA-dependent function system. Specifically, the vehicle function system 123 may be used to provide the OTA main control module 121 with vehicle function status information, such as remaining battery power, gear position and speed information, vehicle mode information, and other vehicle information, so that the OTA system can determine the vehicle status information.

[0103] In some application scenarios, as shown in FIG4 , take the failure of OTA upgrade of the components deployed by the vehicle functional system 123, resulting in component damage, as an example. In this case, when repairing and upgrading the components that failed the OTA upgrade, the OTA main control module 121 cannot obtain the vehicle status information related to the upgrade conditions, for example, the status information of the components that failed the OTA upgrade. In this way, the OTA main control module 121 cannot determine whether the vehicle meets the upgrade conditions corresponding to the repair and upgrade, resulting in the inability to schedule the UA module 122 to flash the data for the repair and upgrade of the components that failed the OTA upgrade, and thus the repair and upgrade of the components that failed the OTA upgrade cannot be achieved.

[0104] In some implementations, the various components of the OTA system 120 in FIG. 3 of the embodiment of the present application, such as the OTA master control module 121 and the UA module 122, can be a physical device or a functional module deployed within a physical device or device. The functional module can be a component in a hardware device, a software function running on dedicated hardware, or a virtualized function instantiated on a platform (e.g., a cloud platform).

[0105] 3 , the OTA server 200 includes: a vehicle type management module 210 , a vehicle management module 220 , an ECU management module 230 , a software management module 240 , a task management module 250 , and a policy management module 260 .

[0106] Among them, the vehicle model management module 210 can be used to manage the difference information of OTA upgrades corresponding to different vehicle models, such as component difference information (high and low configuration information) in different vehicle models, component software difference information, etc.

[0107] The vehicle management module 220 can be used to manage the list of sold vehicles that can provide OTA upgrade services, such as customer information, location, vehicle status, OTA upgrade history information, etc.

[0108] The ECU management module 230 can be used to manage ECU information based on vehicle type, vehicle, etc. For example, the ECU information of a certain vehicle type and the configuration information of each ECU, the ECU information of a certain vehicle and the configuration status information of each ECU, etc.

[0109] The software management module 240 can be used to manage software information based on dimensions such as vehicle type, vehicle, and ECU, including, for example, software package type, software storage address, software version management, and other information.

[0110] The task management module 250 can be used to manage task information, including, for example, the type, status, and task reports of historical tasks. The task management module 250 can also be used to manage task information for online tasks, such as task creation, release status, task execution status, and task results. Task types can include standard upgrades, silent upgrades, and forced upgrades.

[0111] Specifically, standard upgrades are usually functional iterations and updates of components, and generally require user consent (or authorization) to perform the upgrade task. Silent upgrades are usually upgrade tasks performed before the vehicle is sold (for example, when the vehicle is on sale at a vehicle sales and service shop), which do not require user consent (or authorization), but the silent upgrade task will be canceled after the vehicle is sold. When a forced upgrade is performed on a component, the user needs to be aware of it and click to confirm. After the user confirms their consent (or authorization), the upgrade task corresponding to the forced upgrade can only be delayed, and the user cannot cancel this type of upgrade task. It is an upgrade task that performs a mandatory upgrade on the component.

[0112] In an embodiment of the present application, the OTA server can add a rescue mode attribute to the upgrade type of a forced upgrade. Through the rescue mode, a rescue mission can be created to repair a vehicle that has failed the OTA upgrade. For example, the upgrade conditions corresponding to the rescue mode rescue mission can be different from the upgrade conditions corresponding to the non-rescue mode upgrade mission, so that the rescue mission can be performed on the vehicle.

[0113] The policy management module 260 may be used to configure tasks. For example, download conditions, upgrade conditions, upgrade policies, etc. may be configured according to actual tasks.

[0114] It should be noted that Figures 2 and 3 are merely exemplary figures, and the embodiments of this application do not limit the components or the number of components included in the vehicles shown in Figures 2 and 3. In addition to the components shown in Figures 2 and 3, Figures 2 and 3 may also include other components. Furthermore, the names of the components in Figures 2 and 3 are not limited. In addition to the names shown in Figure 3, the various devices may also be named other names, such as names with the same or similar functions, without limitation.

[0115] In some embodiments, the upgrade method according to the embodiments of the present application, implemented based on the application scenario shown in FIG3 and the architecture shown in FIG4 , primarily includes the following steps: Vehicle 100 may receive a first upgrade task sent by OTA server 200 via vehicle-to-cloud channel 300 . This first upgrade task includes a first upgrade package for an OTA upgrade of a first component of vehicle 100 . The OTA main control module 121 in OTA system 120 may obtain vehicle 100 status information from vehicle function system 123 to determine whether vehicle 100 meets a first upgrade condition. If the vehicle 100 meets the first upgrade condition, the first OTA upgrade of the first component may be performed based on the first upgrade package. Specifically, the UA module 122 may flash data on the first component to perform the first OTA upgrade. If the first OTA upgrade fails, the OTA main control module 121 may further obtain vehicle 100 status information after the first OTA upgrade failure from vehicle function system 123 and determine whether the vehicle 100 meets a second upgrade condition. This second upgrade condition does not include conditions associated with the first component and / or a second component, where the second component is the component that caused the first OTA upgrade failure. When the vehicle 100 meets the second upgrade condition, the OTA main control module 121 performs a second OTA upgrade on the first component according to the second upgrade package. In this way, the first component of the vehicle that failed the OTA upgrade can be quickly repaired, improving the efficiency of repairing the vehicle that failed the OTA upgrade.

[0116] The following describes the upgrade method provided by the embodiment of the present application, assuming that the first device is a vehicle, and the vehicle obtains an upgrade task through the OTA server. The upgrade method for the first component is performed as an example. FIG5 is a flow chart of an upgrade method provided by the embodiment of the present application. As shown in FIG5 , the method may include the following steps S101-S108.

[0117] S101. An OTA server sends a first upgrade task to a vehicle, where the first upgrade task includes a first upgrade package.

[0118] In an embodiment of the present application, when a vehicle requires an OTA upgrade of a first component, a first upgrade task is obtained. The first component is the component in the vehicle to be upgraded. For example, the first component may include, but is not limited to, a BMS, a PDU, an MCU, and a PEPS.

[0119] Exemplarily, the vehicle may send an upgrade request to the OTA server, and the OTA server may send a first upgrade task to the vehicle in response to the upgrade request.

[0120] In one implementation, the OTA server may send a first upgrade task to the vehicle via the vehicle-to-cloud channel 300 shown in FIG2 or FIG3 . The first upgrade task includes a first upgrade package, which includes an upgrade file for performing an OTA upgrade on a first component. The first upgrade package can be used to perform an OTA upgrade on the first component of the vehicle.

[0121] S102: The vehicle receives a first upgrade task and detects whether the vehicle meets a first upgrade condition.

[0122] In this embodiment of the present application, after receiving the first upgrade task, the vehicle can save the first upgrade package in the first upgrade task for use in performing an OTA upgrade on the first component. Furthermore, after receiving the first upgrade task, before performing the OTA upgrade on the first component, the vehicle also needs to detect whether the vehicle meets the first upgrade condition to ensure the security of the OTA upgrade of the first component.

[0123] Specifically, when the vehicle detects whether it meets the first upgrade condition, the specific component to be detected can be determined based on the first upgrade condition. For example, if the first upgrade condition corresponds to an entire vehicle component, the vehicle can detect whether the entire vehicle component meets the first upgrade condition. For another example, if the first upgrade condition corresponds to a portion of the vehicle components associated with an OTA upgrade of the first component, the vehicle can detect whether the portion of the vehicle components associated with the OTA upgrade of the first component meets the first upgrade condition.

[0124] The first upgrade condition is the condition corresponding to the OTA upgrade of the first component, and the first upgrade condition includes at least a condition associated with the first component. The first upgrade condition may include one upgrade condition, or may include multiple upgrade conditions. When the first upgrade condition includes multiple upgrade conditions, the multiple upgrade conditions may all be conditions associated with the first component, or at least one of the multiple upgrade conditions may be a condition associated with the first component, and the other upgrade conditions may be conditions associated with other components in the vehicle.

[0125] Exemplarily, the first upgrade condition may include: conditions related to the OTA system (for example, the software package is in place, the software package has passed verification, or the CPU load is normal, etc.), conditions related to the vehicle safety system (for example, the vehicle mode is in upgrade mode, the owner turns on the upgrade authorization state, the vehicle starts to arm, the doors are opened and locked, the vehicle speed and gear are within the upgrade threshold, etc.), and conditions of components related to OTA upgrades (such as the battery charge meets the upgrade requirements, the vehicle high and low voltage status are normal, etc.), etc.

[0126] In one example, taking the IVI system as the first component, since IVI system upgrades take a long time, if the vehicle's battery level is low before the upgrade, there's a possibility that the vehicle will lose power during the upgrade, causing the upgrade to fail. Therefore, the first upgrade condition needs to include: the battery level being greater than a first threshold. Specifically, the first upgrade condition for the IVI system may include: the IVI system being in the upgrade authorization state, the upgrade package being available, the upgrade package being verified, the vehicle being in upgrade mode, and the battery level being greater than the first threshold.

[0127] In another example, taking the BMS as the first component, since the BMS involves safety and battery charge and discharge management, the ACC must be in the OFF position and the vehicle must be powered off and not charging before the upgrade. Therefore, the upgrade conditions must include: the ACC position is in the OFF position and the high-voltage battery charge is not charging. Specifically, the first upgrade conditions corresponding to the BMS may include: the BMS upgrade authorization state is on, the upgrade package is in place, the upgrade package has passed verification, the vehicle mode is upgrade mode, the vehicle gear state is in Park (P), the ACC gear state is in the OFF position, the high-voltage battery charge is not charging, and the battery charge meets the upgrade requirements.

[0128] In one implementation, the detection of whether the vehicle meets the first upgrade condition in S102 may be performed by the OTA master control module 121 (hereinafter referred to as OTA Manger) in the OTA system shown in FIG3 . Specifically, the OTA Manger may query internal information of the OTA system to detect whether the vehicle meets the upgrade condition corresponding to the first component, for example, whether the upgrade package is in place and whether the upgrade package has passed verification.

[0129] OTA Manger can also obtain information from the vehicle's functional systems (such as the energy management system, vehicle mode management system, and power system) through the VCU to detect whether the vehicle meets the first upgrade conditions, such as: the vehicle mode is the upgrade mode, the high-voltage charging status, the high-voltage status of the entire vehicle, the vehicle gear status, the battery charge and battery voltage status, etc.

[0130] S103: When the vehicle meets the first upgrade condition, the vehicle performs a first OTA upgrade on the first component according to the first upgrade package.

[0131] Specifically, when the vehicle meets the first upgrade condition, that is, when the vehicle meets the upgrade condition corresponding to the first component, the vehicle can perform an OTA upgrade on the first component according to the first upgrade package, that is, perform a first OTA upgrade.

[0132] In some embodiments, when the first upgrade condition includes multiple upgrade conditions, the vehicle needs to perform an OTA upgrade on the first component according to the first upgrade package when each of the multiple upgrade conditions is met at the same time.

[0133] In one implementation, S103 may be executed by the UA module 122 in the OTA system shown in Figure 3. For example, the UA module may extract the upgrade file in the first upgrade package, and then flash the system of the first component according to the upgrade file to upgrade the first component.

[0134] S104. When the first OTA upgrade fails, the OTA server obtains the vehicle status information.

[0135] In an embodiment of the present application, in S103, if the vehicle fails to perform a first OTA upgrade of the first component according to the first upgrade package, the OTA server can obtain the vehicle status information for repairing and upgrading the first component (i.e., a second OTA upgrade).

[0136] The vehicle status information is associated with the failure of the first OTA upgrade, that is, the vehicle status information is used to represent the vehicle status information after the failure of the first OTA upgrade of the first component. The vehicle status information can be used to represent, for example, whether the functions of the components in the vehicle are normal, whether the functions of the components in the vehicle meet the upgrade requirements (meet the upgrade conditions), etc.

[0137] Specifically, the vehicle status information may include: status information of a first component, i.e., whether the first component functions normally and whether the first component's functions meet usage requirements. For example, taking the first component as a BMS, the BMS status information may include: whether the battery can be used normally, whether the battery cannot be used normally, whether the battery power meets the upgrade requirements, or whether the battery power does not meet the upgrade requirements.

[0138] The vehicle status information may also include status information of a second component, where the second component is the component that caused the first OTA upgrade to fail. For example, if the first component is the PEPS system, and a battery failure occurs during the first OTA upgrade of the PEPS system, data flashing to the PEPS system will be interrupted, thereby causing the first OTA upgrade to fail, then the second component is the battery.

[0139] In some embodiments, the OTA server can obtain the vehicle status information through one or more of the vehicle's first OTA upgrade log information and user feedback information, that is, determine the status information of the first component and the status information of the second component.

[0140] Specifically, in one implementation, the OTA server can receive the log information of the first OTA upgrade sent by the vehicle's OTA system to obtain the vehicle's status information. The log information is the log information recorded by the OTA Manager during the first OTA upgrade of the first component, and may specifically include: the upgrade process execution action, execution results, upgrade task failure prompt information, etc. The OTA server can obtain the vehicle's status information by extracting the OTA upgrade log information, and further determine the status information of the first component and the status information of the second component.

[0141] In another implementation, the OTA server can also receive user feedback information and obtain vehicle status information. For example, the manager can communicate remotely (such as telephone communication or video communication, etc.) with the user (i.e., the user of the vehicle whose OTA upgrade failed) to obtain status information about the vehicle whose OTA upgrade failed, i.e., user feedback information. For example: the vehicle's battery cannot supply power, the vehicle cannot shift gears, etc. The OTA server can then determine the vehicle's status information such as the battery cannot supply power, the gear shifting system is abnormal, etc. based on the user feedback information.

[0142] S105. The OTA server determines first instruction information according to the vehicle status information, and sends the first instruction information to the vehicle.

[0143] In an embodiment of the present application, the OTA server can determine first indication information based on the vehicle status information obtained in S104. The first indication information can be used to instruct the vehicle to perform a second OTA upgrade according to a second upgrade condition, so as to instruct the vehicle to quickly repair the first component that failed in the first OTA upgrade.

[0144] Exemplarily, when the vehicle's status information includes status information of a first component and status information of a second component, the OTA server can determine first indication information based on the status information of the first component and the status information of the second component, i.e., instructing the vehicle to perform a second OTA upgrade based on a second upgrade condition (i.e., excluding conditions associated with the first component and / or the second component).

[0145] In some embodiments, the first instruction information may be a second upgrade task. Specifically, the task type of the second upgrade task may be a mandatory upgrade task type. That is, after the second upgrade task is issued to the vehicle, the vehicle must be mandatory upgraded according to the second upgrade task. For upgrade tasks of this mandatory upgrade type, the upgrade requires user authorization and approval, and the user does not have the authority to cancel the second upgrade task. This ensures that the vehicle can perform the second OTA upgrade of the first component according to the second upgrade conditions.

[0146] Furthermore, the task type of the second upgrade task can specifically be the first mode (hereinafter referred to as rescue mode) in the forced upgrade task. That is, the upgrade conditions corresponding to the rescue mode are different from the upgrade conditions corresponding to other modes in the forced upgrade task. The upgrade conditions corresponding to the rescue mode can be determined based on the vehicle status information after the first OTA upgrade fails.

[0147] In one implementation, the second upgrade task may include a second upgrade condition, so that the vehicle can obtain the second upgrade condition and perform a second OTA upgrade on the first component according to the second upgrade condition.

[0148] In this case, the second upgrade condition can be determined by the OTA server based on the vehicle's status information. Continuing with the example of S102, where the first component is the BMS and the first upgrade condition, if the first OTA upgrade of the BMS fails, resulting in functional damage, the vehicle status information obtained by the OTA server may include: BMS functional damage, that is, the vehicle is unable to obtain BMS upgrade authorization status, high-voltage charging status, battery power, and other detection results associated with the BMS, and is therefore unable to detect whether the vehicle meets the first upgrade condition: BMS upgrade authorization status, high-voltage charging status is not charged, and battery power meets the upgrade requirement, etc.

[0149] Therefore, the OTA server can determine that the second upgrade condition of the BMS may include: the upgrade package is in place, the upgrade package has passed verification, the vehicle mode is upgrade mode, the vehicle gear state is in park (P), the ACC gear state is in OFF, etc. In this way, the vehicle can perform the second OTA upgrade on the BMS if the second upgrade condition is met.

[0150] In another implementation, the second upgrade task may further include an execution strategy associated with the second upgrade condition. Specifically, the execution strategy may be used to instruct the vehicle to perform a pre-detection step (or pre-step) prior to the second OTA upgrade. That is, the vehicle may perform the pre-step according to the execution strategy to determine whether the vehicle meets the second upgrade condition.

[0151] For example, the execution strategy may include one or more of: not testing the first component, not testing the second component, testing the first component and ignoring the test results of the first component, or testing the second component and ignoring the test results of the second component. In this way, the vehicle performs the pre-steps before the second OTA upgrade according to the execution strategy to detect whether the vehicle meets the second upgrade conditions.

[0152] In some embodiments, the OTA server can receive a task creation instruction (hereinafter referred to as a first instruction) from an administrator to create a second upgrade task. To ensure the safety of the vehicle executing the second upgrade task, the administrator in this embodiment is a person with permission to create the second upgrade task. For example, the administrator can log in to the OTA server using an authorized account and enter the first instruction.

[0153] In one implementation, FIG6 is a schematic diagram of an OTA server creating a second upgrade task according to an embodiment of the present application. As shown in FIG6 , the OTA server display interface may provide an entry option 601 for creating the second upgrade task, such as an advanced option. An administrator can enter the first instruction through this entry option 601.

[0154] In some embodiments, as shown in FIG6 , the entry option 601 can be provided in the display interface of the OTA server logged in by the administrator using an authorized account, while the entry option is not provided in the display interface of the OTA server logged in by ordinary users. This can improve the security of creating the second upgrade task, thereby improving the security of performing the second OTA upgrade on the first component.

[0155] It is understood that the above-mentioned "advanced options" are only exemplary names and do not limit the solutions shown in the embodiments of the present application. For example, "advanced options" can also be replaced with names with the same or similar functions such as "create options" and "generate options".

[0156] In some embodiments, the OTA server can also display risk warning information in the display interface to prompt the user with operation warnings and risk warnings for creating a second upgrade task. Figure 7 is a second schematic diagram of an OTA server creating a second upgrade task provided by an embodiment of the present application. As shown in Figure 7, risk warning information 701 is also displayed in the display interface of the OTA server. The content of the risk warning information 701 may include: High-risk operation warning: Before operating, please make sure that the owner has been notified to park the vehicle in a safe and reliable area, put the vehicle in P gear, remove the safety OBD device, unplug the charging gun, close the car door, and wait by the car, otherwise it may cause serious accidents such as loss of control of the vehicle, damage, and personal safety. In this way, the safety of creating the second upgrade task can be further improved.

[0157] It will be understood that the above risk warning information is for illustrative purposes only and risk warning information may be set according to actual application requirements, and this application does not impose any specific limitations on this.

[0158] In some embodiments, when the second upgrade task includes a second upgrade condition or execution policy, the OTA server may also receive a second policy configuration instruction (hereinafter referred to as the second instruction) from the administrator to configure the second upgrade condition or execution policy in the second upgrade task.

[0159] For example, the OTA server may receive a second instruction indicating a detection condition corresponding to a second OTA upgrade determined based on vehicle status information. The OTA server may determine the detection condition corresponding to the second OTA upgrade as the second upgrade condition based on the second instruction.

[0160] In some embodiments, the second upgrade condition or execution strategy in the above-mentioned second upgrade task can also be sent to the vehicle separately as the first indication information to instruct the vehicle to perform the second OTA upgrade of the first component according to the second upgrade condition.

[0161] In one example, the first indication information may also be a second upgrade condition, that is, the OTA server may directly send the second upgrade condition to the vehicle to instruct the vehicle to perform a second OTA upgrade of the first component according to the received second upgrade condition.

[0162] In another example, the first indication information may also be an execution policy associated with the second upgrade condition. Specifically, the OTA server may directly send the execution policy to the vehicle, instructing the vehicle to execute pre-conditions according to the execution policy to detect whether the vehicle meets the second upgrade condition.

[0163] In one implementation, the OTA server may send the first instruction information to the vehicle via the vehicle-cloud channel 300 shown in FIG2 or FIG3 . Exemplarily, when the first instruction information is an execution policy, or the first instruction information is a second upgrade task, and the second upgrade task includes an execution policy, the execution policy may be, for example, a file in a format such as JavaScript Object Notation (JSON) or Extensible Markup Language (XML), and the OTA server may send the execution policy to the vehicle via a secure wireless communication method based on Datagram Transport Layer Security (DTLS) and Hypertext Transfer Protocol over Secure Socket Layer (HTTPS).

[0164] S106: The vehicle receives the first instruction information and determines whether the vehicle meets the second upgrade condition.

[0165] Specifically, after receiving the first indication information, the vehicle can perform a second OTA upgrade according to the second upgrade condition, that is, detect whether the vehicle meets the second upgrade condition to ensure the safety of the second OTA upgrade of the first component and improve the success rate of the repair and upgrade of the first component.

[0166] For example, since the second upgrade condition does not include conditions associated with the first component and / or the second component, when the vehicle detects whether it meets the second upgrade condition, it includes at least one of the following: not performing a test on the first component, not performing a test on the second component, performing a test on the first component and ignoring the test result obtained from the test on the first component, and performing a test on the second component and ignoring the test result obtained from the test on the second component. In this way, it is possible to quickly determine whether the first device meets the second upgrade condition, thereby improving the efficiency of the second OTA upgrade of the first component.

[0167] In one implementation, the detection of whether the vehicle meets the second upgrade condition in S106 can be performed by the OTA main control module 121 in the OTA system shown in Figure 4. The specific implementation method can refer to the method of the OTA Manger detecting whether the vehicle meets the first upgrade condition in S102 above, which is not repeated here.

[0168] In some embodiments, if the vehicle is pre-configured with a second upgrade condition for the first component, then after the first OTA upgrade fails, the upgrade method provided in the embodiments of the present application may not execute the above steps S104-S106, that is, the vehicle may not need to obtain the first instruction information from the OTA server. After the first OTA upgrade fails, the vehicle can execute the second OTA upgrade according to the pre-configured second upgrade condition, that is, determine whether the vehicle meets the second upgrade condition, and execute the following S107 if the vehicle meets the second upgrade condition.

[0169] In some embodiments, after the first OTA upgrade fails, the vehicle can also obtain the vehicle's status information and determine the second upgrade condition based on the vehicle's status information. In this case, the above S104-S106 may not be executed, and the vehicle may not need to obtain the first indication information from the OTA server. Specifically, the method for the vehicle to determine the second upgrade condition based on the vehicle's status information can refer to the method in S105 where the OTA server determines the second upgrade condition based on the vehicle's status information, which will not be repeated here. After the vehicle determines the second upgrade condition, it can perform the second OTA upgrade based on the second upgrade condition, that is, determine whether the vehicle meets the second upgrade condition, and execute the following S107 when the vehicle meets the second upgrade condition.

[0170] S107. When the vehicle meets the second upgrade condition, the vehicle performs a second OTA upgrade on the first component according to the second upgrade package.

[0171] In an embodiment of the present application, if the vehicle meets the second upgrade condition, that is, if the vehicle meets the upgrade condition corresponding to the second OTA upgrade, the vehicle can perform a second OTA upgrade on the first component based on the second upgrade package. The second upgrade package is associated with the first upgrade package, that is, the second upgrade package can be the same as the first upgrade package, the second upgrade package can also be different from the first upgrade package, and the second upgrade package can also be determined based on the first upgrade package.

[0172] Specifically, if the upgrade content of the first component implemented by the second OTA upgrade is the same as the upgrade content of the first component implemented by the first OTA upgrade, the second upgrade package is the same as the first upgrade package. If the upgrade content of the first component implemented by the second OTA upgrade is different from the upgrade content of the first component implemented by the first OTA upgrade, the second upgrade package is different from the first upgrade package.

[0173] For example, the upgrade content of the first OTA upgrade is an overall upgrade of the first component, and the upgrade content of the second OTA upgrade is a partial upgrade of the part of the first component that failed to upgrade. Then the second upgrade package is different from the first upgrade package, and the second upgrade package can be part of the content of the first upgrade package.

[0174] In some embodiments, when the second upgrade package is the same as the first upgrade package, if the first upgrade package is also stored in the vehicle, the vehicle does not need to obtain the second upgrade package (ie, the first upgrade package).

[0175] In some embodiments, if the second upgrade package is the same as the first upgrade package but the first upgrade package is not saved in the vehicle, or if the second upgrade package is different from the first upgrade package, the vehicle needs to obtain the second upgrade package.

[0176] In one example, in S105, the OTA server may send the second upgrade package to the vehicle at the same time as sending the first instruction information, so that the vehicle obtains the second upgrade package. For example, if the first instruction information is a second upgrade task, the second upgrade task may include the second upgrade package.

[0177] In another example, the vehicle may also obtain the second upgrade package through the OTA server after the vehicle receives the first indication information in S106 and before the vehicle performs a second OTA upgrade on the first component according to the second upgrade package in S107.

[0178] In one implementation, S107 may be performed by the UA module 122 in the OTA system shown in Figure 3. For example, the UA module may extract the upgrade file in the second upgrade package and then flash the system of the second component according to the upgrade file to repair and upgrade the second component.

[0179] In some embodiments, taking the first indication information as a second upgrade task, the second upgrade task including: an execution strategy and a second upgrade package, and the second upgrade task as a rescue mode in a forced upgrade as an example, FIG8 is a flow chart of a second OTA upgrade method provided in an embodiment of the present application. As shown in FIG8 , after the vehicle receives the first indication information, a specific method of performing a second OTA upgrade on the first component may include S201-S204:

[0180] S201: The vehicle determines whether the type of the second upgrade task is a mandatory upgrade.

[0181] S202: If the vehicle determines that the second upgrade task is a mandatory upgrade, the vehicle determines whether the second upgrade task is a rescue mode. Otherwise, the vehicle detects the vehicle according to the upgrade conditions corresponding to the non-mandatory upgrade.

[0182] S203: If the vehicle determines that the second upgrade task is the rescue mode, the vehicle checks whether the vehicle meets the second upgrade condition according to the execution strategy in the second upgrade task. Otherwise, the vehicle checks the vehicle according to the upgrade condition corresponding to the non-rescue mode.

[0183] S204. When the vehicle meets the second upgrade condition, the vehicle flashes data on the first component according to the second upgrade package to perform a second OTA upgrade on the first component.

[0184] By adopting the upgrade method provided in this embodiment, when the first OTA upgrade of the first component fails according to the first upgrade condition, the vehicle can determine whether the vehicle meets the second upgrade condition. If the vehicle meets the second upgrade condition, the first component is upgraded to the second OTA upgrade to repair the vehicle. In this way, the vehicle can perform a second OTA upgrade on the first component of the vehicle when the first component and / or the second component is damaged, or the detection results of the first component and / or the second component cannot be obtained, thereby quickly repairing the vehicle that failed the OTA upgrade, improving the efficiency of vehicle repair and the user experience.

[0185] In some application scenarios, after the vehicle fails to perform an OTA upgrade on the first component, the component in the vehicle may enter a non-working state such as standby or sleep state if it is not working (not operating) for a long time. That is, the component enters a low-load rest state to reduce the vehicle's energy consumption and save energy.

[0186] However, if the component associated with the second OTA upgrade of the first component (hereinafter referred to as the third component) is in a non-operating state, that is, the third component cannot work normally to achieve its corresponding function, the vehicle will be unable to perform the second OTA upgrade on the first component. Therefore, in some embodiments, after the first OTA upgrade fails and before the second OTA upgrade, as shown in Figure 5, the upgrade method provided in the embodiment of the present application further includes:

[0187] S108. The vehicle wakes up the third component.

[0188] Among them, the third component at least includes a component associated with the second OTA upgrade of the first component. Exemplarily, the third component may include a component that needs to be deployed using the OTA Manager when the first component performs the second OTA upgrade. The component deployed by the OTA Manager may be, for example, a T-Box, and the third component may be a T-Box. In this way, the vehicle may not wake up the entire vehicle, but only wake up the third component, so that the third component enters a normal working state, so as to be able to perform the second OTA upgrade on the first component. In this way, not only can it be ensured that the vehicle can perform the second OTA upgrade on the first component, but also the energy consumption of the vehicle can be reduced.

[0189] In some embodiments, the vehicle can send a wake-up command to the third component to instruct the third component to change from a non-operating state (e.g., a dormant state) to an operating state, so that the third component can normally perform its corresponding function. For example, taking the third component as a T-Box, the vehicle can send the wake-up command to the T-Box in the form of a text message. The communication module in the T-Box (e.g., a SIM card text message function module) receives the wake-up command and wakes up the T-Box in response to the wake-up command.

[0190] The wake-up instruction can be determined based on the status information of the third component. Specifically, the vehicle can determine whether the third component is in a non-working state such as a standby state, a dormant state, or a state that cannot be awakened based on the status information of the third component. If the third component is in a non-working state, the wake-up instruction can be determined to wake up the third component. For example, taking the third component as a T-Box, if the status information of the T-Box is: the T-Box is in a state that cannot be awakened, or the T-Box is in a dormant state, that is, the T-Box is in a low-power non-working state, then the wake-up instruction can be determined to wake up the T-Box, so that the T-Box enters a normal working state and realizes the network communication function.

[0191] In one implementation, the wake-up command may include identification information of the third component. The identification information is a unique identifier for the third component, used to distinguish it from other third components. The identification information typically includes the hardware number of the third component or a system-generated string. This allows the vehicle to accurately wake up the third component corresponding to the identification information based on the identification information in the wake-up command.

[0192] In some embodiments, as shown in FIG9 , the vehicle may also receive a wake-up command from the OTA server and, in response to the wake-up command, wake up the third component. The wake-up command may be determined by the OTA server based on the status information of the third component. In S104 above, if the first OTA upgrade fails, the vehicle status information obtained by the OTA server may also include the status information of the third component.

[0193] In some embodiments, the OTA server can obtain the vehicle status information and determine the status information of the third component through one or more of the vehicle's first OTA upgrade log information and user feedback information. The specific implementation method can refer to the implementation method of S104 above and is not repeated here.

[0194] In some embodiments, in S105, the first indication information sent by the OTA server to the vehicle may include a wake-up instruction. For example, if the first indication information is a second upgrade task, the second upgrade task may include a wake-up instruction. In this case, if the second upgrade task also includes an execution strategy, upon receiving the second upgrade task, the vehicle first responds to the wake-up instruction to wake up the third component, and then executes the vehicle's pre-conditioning steps according to the execution strategy. This ensures that the vehicle can execute the pre-conditioning steps to detect whether the vehicle meets the second upgrade condition.

[0195] In some embodiments, in order to improve the safety of the vehicle performing a second OTA upgrade on the first component according to the second upgrade condition, the vehicle may also send a prompt message to ask the user whether to accept the second upgrade condition. Figure 10 is a second flow diagram of an upgrade method provided in an embodiment of the present application. As shown in Figure 10, specifically, another upgrade method provided in an embodiment of the present application includes:

[0196] S301: The vehicle sends a first prompt message.

[0197] In an embodiment of the present application, the vehicle may send a first prompt message before performing a first OTA upgrade on the first component according to the first upgrade condition. For example, the first prompt message may be sent before the above S101 to ask the user whether to accept the second upgrade condition after the first OTA upgrade fails.

[0198] Specifically, the first indication information is used to inquire whether the user of the vehicle accepts the second upgrade condition. The second upgrade condition is the condition for the second OTA upgrade, the second OTA upgrade is the upgrade after the failure of the first OTA upgrade, the first OTA upgrade is the upgrade of the first component of the vehicle according to the first upgrade package when the vehicle meets the first upgrade condition, the first upgrade condition includes at least the condition associated with the first component, the second upgrade condition does not include the condition associated with the first component and / or the second component, and the second component is the component that caused the failure of the first OTA upgrade.

[0199] For example, FIG11 is a schematic diagram showing a first prompt message according to an embodiment of the present application. As shown in FIG11 , the content of the first prompt message 1101 may be: "Please confirm whether to accept the second OTA upgrade of the first component according to the second upgrade condition after the first OTA upgrade of the first component according to the first upgrade condition fails." Specifically, the content of the first prompt message can be set according to actual application requirements and is not specifically limited in this application.

[0200] In one implementation, the content of the above-mentioned first prompt information can be displayed through the display screen of the vehicle computer. As shown in Figure 11, the first prompt information 1101 is displayed in the display interface of the vehicle computer display screen to ask the user whether to accept the second upgrade condition.

[0201] In one implementation, the content of the first prompt information may also be displayed on a display screen of a second device, wherein the second device is a second device of the user using the vehicle, and the second device may include, but is not limited to, a smartphone, a netbook, a tablet computer, a smartwatch, a smart bracelet, a phone watch, a PDA, etc.

[0202] For example, taking the second device as a smartphone, the vehicle can also send the first prompt information to the user's smartphone, which receives and displays the first prompt information on its display screen. Figure 12 is a second schematic diagram of displaying the first prompt information provided in an embodiment of the present application. As shown in Figure 12, the first prompt information 1201 is displayed on the display interface of the smartphone display screen to inquire whether the user accepts the second upgrade condition.

[0203] S302. The vehicle receives first response information from the user, where the first response information is used to indicate whether the user accepts the second upgrade condition.

[0204] In one example, taking the case where the vehicle displays the first indication information through the vehicle computer, the vehicle can receive the first response information from the user through the vehicle computer. As shown in Figure 11, the display interface of the vehicle computer can also include: an acceptance control 1102, that is, the user can click the acceptance control 1102 to send the first response information to the vehicle through the vehicle computer, indicating that the user accepts the second upgrade condition. Among them, the "Accept" control is an exemplary name. The embodiment of the present application does not limit the naming of this control, and it can also be replaced with names with the same or similar functions such as "Confirm" and "Agree".

[0205] In another example, taking the display of the first indication information through the user's second device as an example, the vehicle can also receive the first response information from the user through the second device. As shown in Figure 12, the display interface of the vehicle computer can also include: an acceptance control 1202, that is, the user can click the acceptance control 1202 to send the first response information to the vehicle through the second device, indicating that the user accepts the second upgrade condition. Among them, the "Accept" control is an exemplary name. The embodiment of the present application does not limit the naming of this control, and it can also be replaced with names with the same or similar functions such as "Confirm" and "Agree".

[0206] In some embodiments, if the first response message is not received, the vehicle can confirm that the user does not accept the second upgrade condition. In this way, the security of the vehicle performing the second OTA upgrade can be further improved.

[0207] S303: When the user accepts the second upgrade condition, after the first OTA upgrade fails, the vehicle performs a second OTA upgrade on the first component according to the second upgrade condition.

[0208] If the vehicle receives the first response message indicating that the user accepts the second upgrade condition, then after the first OTA upgrade of the first component fails, the vehicle can perform a second OTA upgrade of the first component according to the second upgrade condition. This improves the security of the vehicle's second OTA upgrade of the first component.

[0209] In some embodiments, in order to further improve the safety of the vehicle performing the second OTA upgrade on the first component, after the first OTA upgrade fails in S303, the vehicle may send a prompt message again to ask the user whether to accept the second OTA upgrade of the first component according to the second upgrade conditions. Specifically, S303 may include S3031-S3033:

[0210] S3031. The vehicle sends a second prompt message.

[0211] In an embodiment of the present application, the vehicle may send a second prompt message after the first OTA upgrade of the first component fails according to the first upgrade condition. For example, after the above S103, the second prompt message may be sent when the first OTA upgrade fails to ask the user whether to accept the second OTA upgrade of the first component according to the second upgrade condition.

[0212] For example, FIG13 is a schematic diagram showing a second prompt message according to an embodiment of the present application. As shown in FIG13 , the content of second prompt message 1301 may be: "The first OTA upgrade of the first component has failed. Please confirm whether to accept the second OTA upgrade of the first component according to the second upgrade condition." Specifically, the content of first prompt message 1301 can be set according to actual application requirements and is not specifically limited in this application.

[0213] In one implementation, after the first OTA upgrade of the first component fails and the vehicle's in-vehicle system functions intactly, as shown in FIG13 , the second prompt information 1301 may be displayed on the display screen of the vehicle's in-vehicle system.

[0214] In one implementation, the content of the second prompt information can also be displayed on the display screen of the second device. For example, taking the second device as a smartphone, the vehicle can also send the second prompt information to the user's smartphone, and the smartphone receives and displays the second prompt information through the display screen. Figure 14 is a second schematic diagram of displaying the second prompt information provided by an embodiment of the present application. As shown in Figure 14, a second prompt information 1401 is displayed in the display interface of the smartphone display screen to ask the user whether to accept the second OTA upgrade of the first component according to the second upgrade condition.

[0215] S3032. The vehicle receives a second response message from the user, where the second response message is used to indicate whether the user accepts a second OTA upgrade of the first component according to a second upgrade condition.

[0216] Based on the second prompt information, the user can determine whether to accept the second OTA upgrade of the first component according to the second upgrade conditions based on the vehicle's status information and actual needs. For example, the user can determine, based on the vehicle's location information, that the vehicle is close to the OTA upgrade center and not accept the second OTA upgrade of the first component according to the second upgrade conditions. The OTA upgrade center can be used to perform the second OTA upgrade of the first component.

[0217] Specifically, similar to the vehicle receiving the first response information in S302 above, the vehicle can receive a second response information from the user via the vehicle computer. Specifically, the user can send the second response information by clicking the accept control 1302 in the vehicle computer display interface as shown in FIG13 . The vehicle can also receive the second response information from the user via a second device. Specifically, the user can send the second response information by clicking the accept control 1402 in the smartphone display interface as shown in FIG14 . Specifically, the method for the vehicle to receive the second response information can refer to the method for the vehicle to receive the first response information described above and is not further described here.

[0218] S3033. When the user accepts the second OTA upgrade of the first component according to the second upgrade condition, the vehicle performs the second OTA upgrade of the first component according to the second upgrade condition.

[0219] If the vehicle receives a notification indicating that the user has accepted the second OTA upgrade of the first component according to the second upgrade conditions, the vehicle can perform the second OTA upgrade of the first component according to the second upgrade conditions. For example, the above-mentioned S106 can be executed to obtain the first prompt information. This improves the security of the vehicle performing the second OTA upgrade of the first component.

[0220] Specifically, the method for a vehicle to perform a second OTA upgrade on a first component according to a second upgrade condition may include: when the vehicle meets the second upgrade condition, performing a second OTA upgrade on the first component according to a second upgrade package, wherein the second upgrade package is associated with the first upgrade package.

[0221] In some embodiments, the vehicle can also determine whether to send the second prompt information based on the vehicle's location information to improve the effectiveness of the second prompt information. Specifically, the above S303 can also include S3034-S3037:

[0222] S3034. The vehicle obtains the vehicle's location information.

[0223] Specifically, the vehicle may obtain location information through its positioning and navigation system. Exemplary positioning and navigation systems include, but are not limited to, the Global Positioning System (GPS), the Global Navigation Satellite System (GLONASS), the Beidou Navigation Satellite System (BDS), the Quasi-Zenith Satellite System (QZSS), and / or the Satellite-Based Augmentation System (SBAS).

[0224] S3035. When the first distance is greater than the first threshold, the vehicle sends a second prompt message.

[0225] Among them, the second prompt message is used to ask the user whether to accept the second OTA upgrade of the first component according to the second upgrade condition. The first distance is associated with the location information of the vehicle. Specifically, the first distance is the distance between the vehicle and the OTA upgrade center, and the OTA upgrade center can be used to perform the second OTA upgrade of the first component. The first threshold can be set by the user according to actual application needs. For example, the first threshold can be 500 meters. In this way, when the distance between the vehicle and the OTA upgrade center is greater than the first threshold, the vehicle sends a second prompt message. Conversely, when the distance between the vehicle and the OTA upgrade center is less than or equal to the first threshold, the vehicle may not send the second prompt message, and the OTA upgrade center's service personnel may go to the vehicle site to perform the second OTA upgrade of the first component and other rescue methods. In this way, not only can the operating process of the second OTA upgrade of the first component be simplified and the power consumption of the vehicle be reduced, but also the effectiveness of the second prompt message and the user experience can be improved.

[0226] S3036. The vehicle receives a second response message from the user, where the second response message is used to indicate whether the user accepts the second OTA upgrade of the first component according to the second upgrade condition.

[0227] S3037. When the user accepts the second OTA upgrade of the first component according to the second upgrade condition, the vehicle performs the second OTA upgrade of the first component according to the second upgrade condition.

[0228] In some embodiments, the OTA server may also send the first prompt information and the second prompt information to the vehicle, and the vehicle may receive and display the first prompt information and the second prompt information sent by the OTA server. FIG15 is a flow chart of an upgrade method provided in an embodiment of the present application. As shown in FIG15 , the upgrade method provided in an embodiment of the present application may further include:

[0229] S401. The OTA server sends a first prompt message to the vehicle.

[0230] S402: The vehicle receives and displays a first prompt message.

[0231] S403: The vehicle receives a first response message from the user.

[0232] S404: When the user accepts the second upgrade condition, after the first OTA upgrade fails, the vehicle performs a second OTA upgrade on the first component according to the second upgrade condition.

[0233] In some embodiments, as shown in FIG16 , in S404 , after the first OTA upgrade fails and before the vehicle performs a second OTA upgrade on the first component according to a second upgrade condition, the method further includes:

[0234] S4041. The OTA server sends a second prompt message to the vehicle.

[0235] S4042: The vehicle receives and displays a second prompt message.

[0236] S4043. The vehicle receives a second response message from the user.

[0237] S4044. When the user accepts the second OTA upgrade of the first component according to the second upgrade condition, the vehicle performs the second OTA upgrade of the first component according to the second upgrade condition.

[0238] It is understandable that, in order to realize the above functions, the above electronic device includes hardware structures and / or software modules corresponding to the execution of each function. Those skilled in the art should easily realize that, 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. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0239] In the embodiment of the present application, the functional modules of the electronic device can be grouped according to the above method example. For example, each functional module can be grouped according to each function, or two or more functions can be integrated into one processing module. The above-mentioned integrated modules can be implemented in the form of hardware or in the form of software functional modules. It should be noted that the grouping of modules in the embodiment of the present application is schematic and is only a logical functional grouping. In actual implementation, there may be other grouping methods.

[0240] An embodiment of the present application also provides an upgrade device, which can be the above-mentioned first device (for example, a vehicle), or a chip in the first device, or a system on chip. The upgrade device can be used to perform the functions of the first device involved in the above-mentioned embodiment.

[0241] As an implementation method, FIG17 is a structural diagram of an upgrade device provided in an embodiment of the present application. As shown in FIG17 , the upgrade device 300 includes: an acquisition module 301 and a processing module 302. The processing module 302 can be, for example, the OTA main control module 121 in the architecture shown in FIG3 . Specifically:

[0242] The acquisition module 301 is configured to acquire a first upgrade task, where the first upgrade task includes a first upgrade package, and the first upgrade package is used for an over-the-air (OTA) upgrade of a first component of a first device.

[0243] The processing module 302 is configured to perform a first OTA upgrade on the first component according to the first upgrade package when the first device meets a first upgrade condition, wherein the first upgrade condition at least includes a condition associated with the first component.

[0244] The processing module 302 is also used to determine whether the first device meets the second upgrade condition when the first OTA upgrade fails. The second upgrade condition does not include conditions associated with the first component and / or the second component, and the second component is the component that causes the failure of the first OTA upgrade.

[0245] The processing module 302 is further configured to perform a second OTA upgrade on the first component according to a second upgrade package when the first device meets a second upgrade condition, wherein the second upgrade package is associated with the first upgrade package.

[0246] In the upgrade device provided in the embodiment of the present application, the processing module 302 can perform a first OTA upgrade on the first component according to the first upgrade task obtained by the acquisition module 301. The processing module 302 can also perform a second OTA upgrade on the first component according to a second upgrade condition if the first OTA upgrade of the first component fails, so as to repair and upgrade the first component.

[0247] In some embodiments, after the first OTA upgrade fails and before the second OTA upgrade, the processing module 302 is specifically used to perform at least one of the following: not performing detection on the first component, not performing detection on the second component, performing detection on the first component and ignoring the detection result obtained by detecting the first component, performing detection on the second component and ignoring the detection result obtained by detecting the second component.

[0248] In some embodiments, after the first OTA upgrade fails, the acquisition module 301 is further configured to acquire first indication information, where the first indication information is configured to instruct execution of a second OTA upgrade according to a second upgrade condition.

[0249] In some embodiments, after the first OTA upgrade fails and before the second OTA upgrade, the processing module 302 is further configured to wake up a third component, wherein the third component includes at least a component associated with the second OTA upgrade of the first component.

[0250] In some embodiments, the acquisition module 301 is further configured to receive a wake-up instruction. The processing module 302 is further configured to wake up the third component in response to the wake-up instruction.

[0251] An embodiment of the present application also provides an upgrade device, which can be the above-mentioned OTA server, or a chip in the OTA server, or a system on chip. The upgrade device can be used to perform the functions of the OTA server involved in the above-mentioned embodiment.

[0252] As an implementation method, FIG18 is a structural diagram of an upgrade device provided in an embodiment of the present application. As shown in FIG18 , the upgrade device 400 includes: a sending module 401. Specifically:

[0253] The sending module 401 is configured to send a first upgrade task, where the first upgrade task includes a first upgrade package, and the first upgrade package is used to perform an OTA upgrade on a first component of a first device.

[0254] The sending module 401 is also used to send a first indication message when the first device fails to perform a first OTA upgrade on the first component according to the first upgrade package, wherein the first indication message is used to instruct the first device to perform a second OTA upgrade according to a second upgrade condition, the second upgrade condition does not include a condition associated with the first component and / or the second component, the second component is the component that caused the failure of the first OTA upgrade, the second OTA upgrade is to upgrade the first component according to the second upgrade package, and the second upgrade package is associated with the first upgrade package.

[0255] In some embodiments, the upgrading device 400 further includes: an acquisition module 402 and a processing module 403 .

[0256] The acquisition module 402 is configured to acquire status information of the first component and / or status information of the second component, where the status information of the first component and / or the status information of the second component is associated with the failure of the first OTA upgrade.

[0257] The processing module 403 is configured to determine a second upgrade condition according to the status information of the first component and / or the second component.

[0258] In some embodiments, the acquisition module 402 is further configured to acquire status information of a third component.

[0259] The processing module 403 is further configured to determine a wake-up instruction according to the status information of the third component.

[0260] The sending module 401 is further configured to send the wake-up instruction determined by the processing module 403 .

[0261] In the upgrade device provided in the embodiment of the present application, processing module 403 can determine a second upgrade condition based on the status information of the first component and / or the status information of the second component acquired by acquisition module 402. Furthermore, sending module 401 can send first indication information to instruct the first device to perform a second OTA upgrade based on the second upgrade condition if the first device fails to perform a first OTA upgrade of the first component based on the first upgrade package. This allows the second OTA upgrade of the first component to be performed as a repair upgrade.

[0262] It should be understood that the division of the modules in the above device is only a division of logical functions. In actual implementation, they can be fully or partially integrated into a physical entity, or they can be physically separated. In addition, the modules in the device can be implemented in the form of a processor calling software; for example, the device includes a processor, the processor is connected to a memory, and the memory stores instructions. The processor calls the instructions stored in the memory to implement any of the above methods or realize the functions of the modules of the device, wherein the processor is, for example, a general-purpose processor, such as a central processing unit (CPU) or a microprocessor, and the memory is a memory within the device or a memory outside the device. Alternatively, the modules in the device can be implemented in the form of hardware circuits, and the functions of some or all modules can be realized by designing the hardware circuits. The hardware circuit can be understood as one or more processors. For example, in one implementation, the hardware circuit is an application-specific integrated circuit (ASIC), which realizes the functions of some or all of the above modules by designing the logical relationship of the components in the circuit. For another example, in another implementation, the hardware circuit can be implemented by a programmable logic device (PLD). Taking a field programmable gate array (FPGA) as an example, it can include a large number of logic gate circuits, and the connection relationship between the logic gate circuits is configured by configuring the configuration file, thereby realizing the functions of some or all of the above modules. All modules of the above devices can be implemented in the form of software called by the processor, or in the form of hardware circuits, or in part by the form of software called by the processor, and the rest by hardware circuits.

[0263] In an embodiment of the present application, a processor is a circuit with the ability to process signals. In one implementation, the processor may be a circuit with the ability to read and execute instructions, such as a central processing unit (CPU), a microprocessor, a graphics processing unit (GPU) (which can be understood as a microprocessor), or a digital signal processor (DSP); in another implementation, the processor may implement certain functions through the logical relationship of a hardware circuit, and the logical relationship of the hardware circuit is fixed or reconfigurable, such as a hardware circuit implemented by an application-specific integrated circuit (ASIC) or a programmable logic device (PLD), such as an FPGA. In a reconfigurable hardware circuit, the process of the processor loading a configuration document to implement the hardware circuit configuration can be understood as the process of the processor loading instructions to implement the functions of some or all of the above modules. In addition, it can also be a hardware circuit designed for artificial intelligence, which can be understood as an ASIC, such as a neural network processing unit (NPU), a tensor processing unit (TPU), a deep learning processing unit (DPU), etc.

[0264] It can be seen that each module in the above device can be one or more processors (or processing circuits) configured to implement the above method, such as: CPU, GPU, NPU, TPU, DPU, microprocessor, DSP, ASIC, FPGA, or a combination of at least two of these processor forms.

[0265] In addition, the modules in the above device can be fully or partially integrated together, or can be implemented independently. In one implementation, these modules are integrated together and implemented in the form of a system-on-a-chip (SOC). The SOC may include at least one processor for implementing any of the above methods or implementing the functions of the modules of the device. The type of the at least one processor can be different, for example, including a CPU and FPGA, a CPU and an artificial intelligence processor, a CPU and a GPU, etc.

[0266] An embodiment of the present application further provides a vehicle, comprising the aforementioned upgrade device, such as upgrade device 300. The device enables the vehicle to perform a first OTA upgrade on a first component in the vehicle according to a first upgrade task obtained. If the first OTA upgrade fails, the vehicle can perform a second OTA upgrade on the first component according to a second upgrade condition to repair and upgrade the first component.

[0267] An embodiment of the present application also provides an electronic device, which may include: a memory and one or more processors. The memory and the processor are coupled. The memory is used to store computer program code, which includes computer instructions. When the processor executes the computer instructions, the electronic device may execute the various functions or steps performed by the vehicle in the above method embodiment, or the electronic device may execute the various functions or steps performed by the OTA server in the above method embodiment. Of course, the electronic device includes but is not limited to the above memory and one or more processors. For example, the structure of the electronic device can refer to the structure of the vehicle and the structure of the OTA server shown in Figure 3.

[0268] The embodiment of the present application also provides a chip system, which can be applied to the electronic devices in the aforementioned embodiments. As shown in Figure 19, the chip system includes at least one processor 501 and at least one interface circuit 502. The processor 501 can be the processor in the above-mentioned electronic device. The processor 501 and the interface circuit 502 can be interconnected through lines. The processor 501 can receive and execute computer instructions from the memory of the above-mentioned electronic device through the interface circuit 502. When the computer instructions are executed by the processor 501, the electronic device can execute the various steps executed by the vehicle in the above-mentioned embodiment, or the electronic device can execute the various steps executed by the OTA server in the above-mentioned embodiment. Of course, the chip system can also include other discrete devices, which are not specifically limited in the embodiment of the present application.

[0269] An embodiment of the present application also provides a computer-readable storage medium for storing computer instructions executed by the above-mentioned electronic device.

[0270] An embodiment of the present application also provides a computer program product, including computer instructions executed by the above electronic device.

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

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

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

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

[0275] 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 part that contributes to the prior art 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 (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.

[0276] In the various embodiments of the present application, unless otherwise specified or logically conflicting, the terms and / or descriptions between the various embodiments are consistent and can be referenced from each other. The technical features in different embodiments can be combined to form new embodiments based on their inherent logical relationships. The above content is only a specific implementation method of the present application, but the scope of protection of the present application is not limited thereto. Any changes or replacements within the technical scope disclosed in the present application should be included in the scope of protection of the present application. Therefore, the scope of protection of the present application should be based on the scope of protection of the claims.

Claims

1. An upgrading method, characterized in that: The method comprises: Obtaining a first upgrade task, the first upgrade task including a first upgrade package, the first upgrade package being used for an over-the-air (OTA) upgrade of a first component of a first device; When the first device meets a first upgrade condition, performing a first OTA upgrade on the first component according to the first upgrade package, wherein the first upgrade condition at least includes a condition associated with the first component; When the first OTA upgrade fails, determining whether the first device satisfies a second upgrade condition, where the second upgrade condition does not include a condition associated with the first component and / or a second component, and the second component is a component that causes the first OTA upgrade to fail; When the first device meets the second upgrade condition, a second OTA upgrade is performed on the first component according to a second upgrade package, wherein the second upgrade package is associated with the first upgrade package.

2. The method according to claim 1, characterized in that After the first OTA upgrade fails and before the second OTA upgrade, the method further includes at least one of the following: not performing detection on the first component; not performing detection on the second component; Performing a test on the first component and ignoring a test result obtained by testing the first component; Detection of the second component is performed and a detection result obtained by detecting the second component is ignored.

3. The method according to claim 1 or 2, characterized in that: After the first OTA upgrade fails, the method further includes: Obtain first indication information, where the first indication information is used to indicate that the second OTA upgrade is to be performed according to the second upgrade condition.

4. The method according to any one of claims 1 to 3, characterized in that: The second upgrade condition is determined based on status information of the first component and / or the second component, and the status information of the first component and / or the second component is associated with the failure of the first OTA upgrade.

5. The method according to any one of claims 1 to 4, characterized in that: After the first OTA upgrade fails and before the second OTA upgrade, the method further includes: A third component is awakened, wherein the third component includes at least a component associated with performing the second OTA upgrade on the first component.

6. The method according to claim 5, characterized in that The waking up the third component comprises: receiving a wake-up instruction, wherein the wake-up instruction is used to wake up the third component; In response to the wake-up instruction, the third component is woken up.

7. The method according to claim 6, characterized in that The wake-up instruction is determined according to the status information of the third component.

8. The method according to any one of claims 1 to 7, characterized in that: The upgrade type corresponding to the second OTA upgrade is a forced upgrade.

9. An upgrading method, characterized in that: The method comprises: Sending a first upgrade task, where the first upgrade task includes a first upgrade package, where the first upgrade package is used to perform OTA upgrade on a first component of a first device; In case that the first device fails to perform a first OTA upgrade on the first component according to the first upgrade package, a first indication message is sent, wherein the first indication message is used to instruct the first device to perform a second OTA upgrade according to a second upgrade condition, the second upgrade condition does not include a condition associated with the first component and / or the second component, the second component is the component that caused the failure of the first OTA upgrade, the second OTA upgrade is to upgrade the first component according to a second upgrade package, and the second upgrade package is associated with the first upgrade package.

10. The method according to claim 9, characterized in that The first device performs the second OTA upgrade according to the second upgrade condition, including at least one of the following: not performing detection on the first component; not performing detection on the second component; Performing a test on the first component and ignoring a test result obtained by testing the first component; Detection of the second component is performed and a detection result obtained by detecting the second component is ignored.

11. The method according to claim 9 or 10, characterized in that: Before sending the first indication information, the method further includes: Obtaining status information of the first component and / or status information of the second component, where the status information of the first component and / or the status information of the second component is associated with the failure of the first OTA upgrade; The second upgrade condition is determined according to the status information of the first component and / or the second component.

12. The method according to claim 11, characterized in that The acquiring the status information of the first component and / or the second component includes: Receiving one or more of log information and user feedback information of the first OTA upgrade; According to one or more of the log information and the user feedback information, status information of the first component and / or the second component is determined.

13. The method according to any one of claims 9 to 12, characterized in that: After the first OTA upgrade fails and before the second OTA upgrade, the method further includes: Send a wake-up instruction, where the wake-up instruction is used to wake up a third component, wherein the third component at least includes a component associated with performing the second OTA upgrade on the first component.

14. The method according to claim 13, characterized in that Before sending the wake-up instruction, the method further includes: Acquiring status information of the third component; The wake-up instruction is determined according to the status information of the third component.

15. The method according to claim 14, characterized in that The obtaining the status information of the third component includes: Receiving one or more of log information and user feedback information of the first OTA upgrade; Determine the status information of the third component according to one or more of the log information and the user feedback information.

16. The method according to any one of claims 9 to 15, characterized in that: The upgrade type corresponding to the second OTA upgrade is a forced upgrade.

17. An upgrading method, characterized in that: The method comprises: Send a first prompt message, wherein the first indication message is used to ask a user using the first device whether to accept the a second upgrade condition, wherein the second upgrade condition is a condition for a second OTA upgrade, the second OTA upgrade is an upgrade after the first OTA upgrade fails, the first OTA upgrade is an upgrade of a first component of the first device according to a first upgrade package when the first device meets the first upgrade condition, the first upgrade condition at least includes a condition associated with the first component, the second upgrade condition does not include a condition associated with the first component and / or a second component, and the second component is a component that causes the first OTA upgrade to fail; receiving first response information from a user, where the first response information is used to indicate whether the user accepts the second upgrade condition; In a case where the user accepts the second upgrade condition, after the first OTA upgrade fails, the second OTA upgrade is performed on the first component according to the second upgrade condition.

18. The method according to claim 17, characterized in that After the first OTA upgrade fails, the method further includes: Sending a second prompt message, where the second prompt message is used to inquire whether the user accepts the second OTA upgrade of the first component according to the second upgrade condition; receiving second response information from a user, where the second response information is used to indicate whether the user accepts the second OTA upgrade of the first component according to the second upgrade condition; In a case where the user accepts the second OTA upgrade of the first component according to the second upgrade condition, the second OTA upgrade of the first component is performed according to the second upgrade condition.

19. The method according to claim 18, characterized in that After the first OTA upgrade fails, the method further includes: Acquire location information of the first device; When the first distance is greater than a first threshold, sending a second prompt message, wherein the second prompt message is used to inquire whether the user accepts the second OTA upgrade of the first component according to the second upgrade condition, the first distance is associated with the location information, the first distance is the distance between the first device and an OTA upgrade center, and the OTA upgrade center is used to perform the second OTA upgrade on the first component; receiving second response information from a user, where the second response information is used to indicate whether the user accepts the second OTA upgrade of the first component according to the second upgrade condition; In a case where the user accepts the second OTA upgrade of the first component according to the second upgrade condition, the second OTA upgrade of the first component is performed according to the second upgrade condition.

20. The method according to any one of claims 17 to 19, characterized in that: After the first OTA upgrade fails, the method further includes: Obtain first indication information, where the first indication information is used to indicate that the second OTA upgrade is to be performed according to the second upgrade condition.

21. The method according to any one of claims 17 to 20, characterized in that: The performing the second OTA upgrade on the first component according to the second upgrade condition includes: When the first device meets the second upgrade condition, a second OTA upgrade is performed on the first component according to a second upgrade package, wherein the second upgrade package is associated with the first upgrade package.

22. An upgrading method, characterized in that: The method comprises: Receive and display a first prompt message, wherein the first prompt message is used to ask a user using the first device whether to accepting a second upgrade condition, where the second upgrade condition is a condition for a second OTA upgrade, where the second OTA upgrade is an upgrade after a first OTA upgrade fails, where the first OTA upgrade is an upgrade of a first component of the first device according to a first upgrade package when the first device satisfies the first upgrade condition, where the first upgrade condition at least includes a condition associated with the first component, where the second upgrade condition does not include a condition associated with the first component and / or a second component, and where the second component is a component that causes the first OTA upgrade to fail; receiving first response information from a user, where the first response information is used to indicate whether the user accepts the second upgrade condition; In a case where the user accepts the second upgrade condition, after the first OTA upgrade fails, the second OTA upgrade is performed on the first component according to the second upgrade condition.

23. The method according to claim 22, characterized in that After the first OTA upgrade fails, the method further includes: receiving and displaying a second prompt message, where the second prompt message is used to inquire whether the user accepts the second OTA upgrade of the first component according to the second upgrade condition; receiving second response information from a user, where the second response information is used to indicate whether the user accepts the second OTA upgrade of the first component according to the second upgrade condition; In a case where the user accepts the second OTA upgrade of the first component according to the second upgrade condition, the second OTA upgrade of the first component is performed according to the second upgrade condition.

24. The method according to claim 22, characterized in that After the first OTA upgrade fails, the method further includes: Acquire location information of the first device; When the first distance is greater than a first threshold, receiving and displaying second prompt information, the second prompt information is used to inquire the user whether to accept the second OTA upgrade of the first component according to the second upgrade condition, the first distance is associated with the location information, the first distance is the distance between the first device and an OTA upgrade center, and the OTA upgrade center is used to perform the second OTA upgrade on the first component; receiving second response information from a user, where the second response information is used to indicate whether the user accepts the second OTA upgrade of the first component according to the second upgrade condition; In a case where the user accepts the second OTA upgrade of the first component according to the second upgrade condition, the second OTA upgrade of the first component is performed according to the second upgrade condition.

25. An upgrading method, characterized in that: The method comprises: Sending a first prompt information, where the first indication information is used to inquire whether a user using the first device accepts a second upgrade condition, where the second upgrade condition is a condition for a second OTA upgrade, where the second OTA upgrade is an upgrade after the first OTA upgrade fails, where the first OTA upgrade is an upgrade of a first component of the first device according to a first upgrade package when the first device satisfies the first upgrade condition, where the first upgrade condition at least includes a condition associated with the first component, where the second upgrade condition does not include a condition associated with the first component and / or the second component, and where the second component is a component that causes the first OTA upgrade to fail; In a case where the user accepts the second upgrade condition, after the first OTA upgrade fails, first indication information is sent, wherein the first indication information is used to instruct the first device to perform a second OTA upgrade according to the second upgrade condition.

26. The method according to claim 25, characterized in that After the first OTA upgrade fails and before the sending of the first indication information, the method further includes: Send a second prompt message, where the second prompt message is used to inquire the user whether to accept the second OTA upgrade of the first component according to the second upgrade condition.

27. An upgrading device, characterized in that: The device comprises: an acquisition module and a processing module, wherein: The acquisition module is used to acquire a first upgrade task, where the first upgrade task includes a first upgrade package, where the first upgrade package is used for an over-the-air (OTA) upgrade of a first component of a first device; The processing module is configured to perform a first OTA upgrade on the first component according to the first upgrade package when the first device meets a first upgrade condition, wherein the first upgrade condition at least includes a condition associated with the first component; The processing module is further configured to determine, when the first OTA upgrade fails, whether the first device satisfies a second upgrade condition, where the second upgrade condition does not include a condition associated with the first component and / or a second component, and the second component is a component that causes the first OTA upgrade to fail; The processing module is further configured to perform a second OTA upgrade on the first component according to a second upgrade package when the first device meets the second upgrade condition, wherein the second upgrade package is associated with the first upgrade package.

28. The device according to claim 27, characterized in that After the first OTA upgrade fails, the acquisition module is further used to: Obtain first indication information, where the first indication information is used to indicate that the second OTA upgrade is to be performed according to the second upgrade condition.

29. An upgrading device, characterized in that: The device comprises: a sending module; The sending module is used to send a first upgrade task, where the first upgrade task includes a first upgrade package, and the first upgrade package is used to perform OTA upgrade on a first component of a first device; The sending module is also used to send a first indication message when the first device fails to perform a first OTA upgrade on the first component according to the first upgrade package, wherein the first indication message is used to instruct the first device to perform a second OTA upgrade according to a second upgrade condition, the second upgrade condition does not include a condition associated with the first component and / or the second component, the second component is the component that caused the failure of the first OTA upgrade, the second OTA upgrade is to upgrade the first component according to a second upgrade package, and the second upgrade package is associated with the first upgrade package.

30. The device according to claim 29, characterized in that The device further comprises: an acquisition module and a processing module, wherein: The acquisition module is configured to acquire status information of the first component and / or status information of the second component, where the status information of the first component and / or the status information of the second component is associated with the failure of the first OTA upgrade; The processing module is used to determine the second upgrade condition according to the status information of the first component and / or the second component.

31. A vehicle, characterized in that: It comprises: an upgrading device, wherein the upgrading device is used to execute the method according to any one of claims 1 to 8, or the method according to any one of claims 17 to 21, or the method according to any one of claims 22 to 24.

32. An electronic device, characterized in that: include: A memory, one or more processors; the memory is coupled to the processor; wherein the memory stores computer program code, the computer program code includes computer instructions, and when the computer instructions are executed by the processor, the electronic device executes the method as described in any one of claims 1 to 8, or the electronic device executes the method as described in any one of claims 9 to 16, or the electronic device executes the method as described in any one of claims 17 to 21, or the electronic device executes the method as described in any one of claims 22 to 24, or the electronic device executes the method as described in claim 25 or 26.

33. A computer-readable storage medium, characterized in that: Comprising computer instructions, when the computer instructions are executed on an electronic device, the electronic device executes the method as described in any one of claims 1 to 8, or the electronic device executes the method as described in any one of claims 9 to 16, or the electronic device executes the method as described in any one of claims 17 to 21, or the electronic device executes the method as described in any one of claims 22 to 24, or the electronic device executes the method as described in claim 25 or 26.

Images