Device rescue method and related device

Abstract

An embodiment of the present application discloses a device rescue method, which can be applied to a scenario such as vehicle rescue. The method includes the following steps: after a vehicle fails to perform an update, the vehicle transmits first information, including update failure information for multiple components, to a server, and then receives second information from the server for triggering a rescue update task, the rescue update task relating to a target component among the multiple components that should be re-updated; the vehicle then executes a strategy corresponding to the rescue update task to re-update the target component, and the strategy is used to restrict driving of the vehicle; the server can automatically determine the target component that should be re-updated based on the update failure information reported by the vehicle; and because the vehicle automatically executes the strategy corresponding to the rescue update task to re-update the target component in a timely manner, problems such as vehicle power loss and battery over-discharge caused by the update failure can be reduced.

Description

[Technical Field]

[0001] [Technical field] TECHNICAL FIELD Embodiments of the present application relate to the field of communication technologies, and more particularly to a device rescue method and related device. [Background technology]

[0002] With the development of autonomous driving, people are demanding increasingly advanced computing and control capabilities from vehicles. More and more functions are being provided to users in the form of software. Therefore, software-defined vehicles have become an important trend in vehicle development.

[0003] Currently, vehicles with software to be installed or updated must connect to the cloud using over-the-air (OTA) technology. Every time a vehicle sends an update request to an OTA server, the OTA server responds to the vehicle's update request and delivers a vehicle update package to the vehicle. The vehicle then performs the OTA update. If the vehicle's OTA update fails, a technician analyzes the cause of the update failure, creates an update task, and re-updates the vehicle based on the update task.

[0004] However, due to the uncertainty of when a technician will create the update task, it is possible that a vehicle's OTA update could fail for several hours, causing issues such as the vehicle losing power or the battery being deeply discharged. Summary of the Invention

[0005] SUMMARY OF THE INVENTION Embodiments of the present application provide a device rescue method and related device that can reduce problems such as vehicle power loss and battery over-discharge caused by update failures.

[0006] A first aspect of an embodiment of the present application provides a method for rescuing a device, which can be applied to a scenario such as rescuing a vehicle. The method may be executed by a first terminal device or a component (e.g., a processor, a chip, or a chip system) of the first terminal device. The first terminal device may specifically be a device such as a vehicle or a robot. The method includes: sending first information to a server, the first information including update failure information of a plurality of components in the first terminal device; receiving second information from the server, the second information being used to trigger a rescue update task of the first terminal device, the rescue update task relating to a target component to be re-updated among the plurality of components; Executing a strategy corresponding to the rescue update task, the strategy being used to restrict operation of the first terminal device; and re-updating the target component.

[0007] In this embodiment of the present application, after a vehicle fails to update, the vehicle transmits first information to a server, including update failure information for the plurality of components, and then receives second information from the server for triggering the rescue update task, the rescue update task relating to a target component among the plurality of components that should be re-updated. The vehicle then executes a strategy corresponding to the rescue update task to re-update the target component, and the strategy is used to restrict driving of the vehicle. The server can automatically determine the target component that should be re-updated based on the update failure information reported by the vehicle. Furthermore, because the vehicle automatically executes a strategy corresponding to the rescue update task to re-update the target component in a timely manner, problems such as vehicle power loss and battery over-discharge caused by the update failure can be reduced.

[0008] Optionally, in a possible implementation of the first aspect, the strategy includes at least one of performing a high voltage turn-off operation and ignoring a precondition check for the first terminal device, the preconditions including at least one of a power check for the first terminal device and a power supply check for the terminal device.

[0009] In this possible implementation, a high voltage turn-off operation is performed to prevent driver interaction during the update process, and the vehicle power and power supply checks are ignored to quickly enter the re-update phase, improving the execution rate of the update flash.

[0010] Optionally, in a possible implementation of the first aspect, the target component includes at least one of a power component of the first terminal device and a power supply component of the first terminal device.

[0011] In this possible implementation, the primary signals related to power or power supply after an update failure are re-updated to ensure normal power or power supply of the vehicle.

[0012] Optionally, in a possible implementation of the first aspect, after the step of re-updating the target component, the method further comprises: The method further includes sending third information to the server, the third information indicating that the target component has been successfully updated.

[0013] In this possible implementation, after the re-update is successful, the update success information is fed back to the server, which can notify the user and record the update information for the vehicle.

[0014] A second aspect of an embodiment of the present application provides a device rescue method, which can be applied to a scenario such as vehicle rescue. The method may be performed by a server or a component of the server (e.g., a processor, a chip, or a chip system). The server may specifically be a device such as an OTA server. The method includes: receiving first information from a first terminal device, the first information including update failure information of a plurality of components in the first terminal device; determining a target component to be re-updated among the plurality of components based on the first information; determining a rescue update task for the target component; The method includes a step of transmitting second information to the first terminal device, wherein the second information is used to trigger the first terminal device to execute a strategy corresponding to the rescue update task, and the strategy is used to limit the operation of the first terminal device.

[0015] In this embodiment of the present application, after a vehicle fails to update, the server receives update failure information for the plurality of components sent by the vehicle and then determines the rescue update task based on the actual failure information, where the rescue update task is related to a target component among the plurality of components that should be re-updated. Furthermore, the vehicle executes a strategy corresponding to the rescue update task to re-update the target component, and the strategy is used to restrict driving of the vehicle. The server can automatically determine the target component that should be re-updated based on the update failure information reported by the vehicle. Furthermore, the vehicle automatically executes a strategy corresponding to the rescue update task to re-update the target component in a timely manner, thereby reducing problems such as vehicle power loss and battery over-discharge caused by the update failure.

[0016] Optionally, in a possible implementation of the second aspect, before the step of determining a repair update task for the target component, the method further includes a step of determining an update failure level of the target component, wherein the step of determining a repair update task for the target component includes determining the repair update task based on the update failure level if a preset condition is satisfied, the preset condition including that the update failure level is a target level.

[0017] In this possible implementation, whether to deliver the rescue update task is determined based on the update failure level, and the entire process can be performed automatically, allowing the vehicle to be rescued quickly.

[0018] Optionally, in a possible implementation of the second aspect, the preset condition further includes that the target component is at least one of a power component of the first terminal device and a power supply component of the first terminal device.

[0019] In this possible implementation, whether to deliver the rescue update task is further determined based on whether the target component is a key component related to power and / or power supply.

[0020] Optionally, in a possible implementation of the second aspect, after the step of transmitting second information to the first terminal device, the method further comprises: The method further includes receiving third information from the first terminal device, the third information indicating that the target component has been successfully updated.

[0021] In this possible implementation, after the re-update is successful, the server receives update success information fed back by the vehicle, and the server can notify the user and record the update information of the vehicle.

[0022] Optionally, in a possible implementation of the second aspect, before determining a rescue update task for the target component among the plurality of components based on the first information, the method further includes sending first prompt information to a second terminal device, the first prompt information indicating that the server will distribute the rescue update task to the second terminal device. After receiving third information from the first terminal device, the method further includes sending second prompt information to the second terminal device, the second prompt information indicating that the first terminal device has been successfully updated.

[0023] In this possible implementation, the second prompt information is sent to the second terminal device, so that the user can be aware of the automatic rescue and does not have to worry about whether the user can drive normally when the update fails.

[0024] Optionally, in a possible implementation form of the second aspect, before the step of determining a rescue update task for the target component among the plurality of components based on the first information, the method further comprises: The method further includes a step of receiving activation information from the second terminal device, the activation information being used by a user to decide to activate the function of the rescue update task.

[0025] In this possible implementation, the user can enable the "automatic rescue in case of update failure" function by performing an operation on the vehicle's central control screen or a mobile phone application, and after an OTA update failure, the vehicle can be rescued based on a strategy corresponding to the rescue update task.

[0026] A third aspect of the present embodiment provides a first terminal device, which can be applied to a scenario such as vehicle rescue. a sending unit configured to send first information to a server, the first information including update failure information of a plurality of components in the first terminal device; a receiving unit configured to receive second information from the server, the second information being used to trigger a rescue update task of the first terminal device, the rescue update task being related to a target component to be re-updated among the plurality of components; a processing unit configured to execute a strategy corresponding to the rescue update task, the strategy being used to restrict operation of the first terminal device, the processing unit further configured to re-update the target component.

[0027] Optionally, in a possible implementation of the third aspect, the strategy includes at least one of performing a high voltage turn-off operation and ignoring a precondition check for the first terminal device, the preconditions including at least one of a power check for the first terminal device and a power supply check for the terminal device.

[0028] Optionally, in a possible implementation of the third aspect, the target component includes at least one of a power component of the first terminal device and a power supply component of the first terminal device.

[0029] Optionally, in a possible implementation of the third aspect, the sending unit is further configured to send third information to the server, the third information indicating that the target component has been successfully updated.

[0030] A fourth aspect of an embodiment of the present application provides a server, which can be applied to a scenario such as vehicle rescue, the server comprising: a receiving unit configured to receive first information from a first terminal device, the first information including update failure information of a plurality of components in the first terminal device; a processing unit configured to determine a target component to be re-updated among the plurality of components based on the first information, the processing unit further configured to determine a rescue update task for the target component; A transmitting unit configured to transmit second information to the first terminal device, the second information being used to trigger the first terminal device to execute a strategy corresponding to the rescue update task, the strategy being used to limit the operation of the first terminal device.

[0031] Optionally, in a possible implementation of the fourth aspect, the processing unit is further configured to determine an update failure level of a target component, and the processing unit is specifically configured to determine the rescue update task based on the update failure level when a preset condition is satisfied, the preset condition including that the update failure level is a target level.

[0032] Optionally, in a possible implementation of the fourth aspect, the preset condition further includes that the target component is at least one of a power component of the first terminal device and a power supply component of the first terminal device.

[0033] Optionally, in a possible implementation of the fourth aspect, the receiving unit is further configured to receive third information from the first terminal device, the third information indicating that the target component has been successfully updated.

[0034] Optionally, in a possible implementation of the fourth aspect, the sending unit is further configured to send first prompt information to a second terminal device, the first prompt information indicating that the server will distribute the rescue update task to the second terminal device, and the sending unit is further configured to send second prompt information to the second terminal device, the second prompt information indicating that the first terminal device has been successfully updated.

[0035] Optionally, in a possible implementation of the fourth aspect, the receiving unit is further configured to receive activation information from the second terminal device, and the activation information is used by a user to decide to activate the functionality of the rescue update task.

[0036] A fifth aspect of an embodiment of the present application provides a first terminal device including a processor, the processor coupled to a memory, the memory configured to store a program or instructions, the program or instructions being executed by the processor to enable the first terminal device to perform a method according to the first aspect or any one of the possible implementations of the first aspect.

[0037] A sixth aspect of an embodiment of the present application provides a server including a processor, the processor coupled to a memory, the memory configured to store a program or instructions, the program or instructions being executed on the processor to enable the server to perform a method according to the second aspect or any one of the possible implementations of the second aspect.

[0038] A seventh aspect of the present embodiment provides a communication system including the communication device of the fifth aspect and / or the communication device of the sixth aspect.

[0039] An eighth aspect of an embodiment of the present application provides a vehicle including a first terminal device according to the second aspect or any one of the possible implementations of the second aspect.

[0040] A ninth aspect of an embodiment of the present application provides a computer-readable medium, the computer-readable medium storing a computer program or instructions, which, when executed on a computer, enables the computer to perform a method according to the first aspect or any one of its possible implementations, or enables the computer to perform a method according to the second aspect or any one of its possible implementations.

[0041] A tenth aspect of the present application provides a computer program product, which, when run on a computer, enables the computer to perform a method according to the first aspect or any one of its possible implementations, or enables the computer to perform a method according to the second aspect or any one of its possible implementations.

[0042] From the above technical solution, it can be seen that the embodiment of the present application has the following advantages: After a vehicle fails to update, the vehicle transmits first information to a server, including update failure information of the plurality of components, and then receives second information from the server for triggering the rescue update task, the rescue update task relating to a target component among the plurality of components that should be re-updated. Furthermore, the vehicle executes a strategy corresponding to the rescue update task to re-update the target component, and the strategy is used to restrict driving of the vehicle. The server can automatically determine the target component that should be re-updated based on the update failure information reported by the vehicle. Furthermore, the vehicle automatically executes a strategy corresponding to the rescue update task to re-update the target component in a timely manner, thereby reducing problems such as vehicle power loss and battery over-discharge caused by the update failure. [Brief explanation of the drawings]

[0043] [Figure 1] FIG. 1 is a diagram of the structure of a network architecture according to an embodiment of the present application; [Figure 2] FIG. 2 is another structural diagram of a network architecture according to an embodiment of the present application; [Figure 3] 1 is a schematic flow chart of a device rescue method according to an embodiment of the present application; [Figure 4] 3 is another schematic flow chart of a device rescue method according to an embodiment of the present application; [Figure 5] FIG. 1 is an exemplary diagram of an application scenario according to an embodiment of the present application; [Figure 6] FIG. 10 is an exemplary diagram of a central control screen interface according to an embodiment of the present application. [Figure 7] FIG. 1 is an exemplary diagram of an interaction between a user and a vehicle central control according to an embodiment of the present application. [Figure 8] 1 is an exemplary diagram of an interaction between a user and an application on a mobile phone according to an embodiment of the present application; [Figure 9] FIG. 2 is a structural diagram of a first terminal device according to an embodiment of the present application; [Figure 10] FIG. 2 is a structural diagram of a server according to an embodiment of the present application; [Figure 11] FIG. 2 is another structural diagram of a server according to an embodiment of the present application; DETAILED DESCRIPTION OF THE INVENTION

[0044] The present invention provides a device rescue method and a related device. A server can automatically determine target components to be updated based on update failure information reported by a vehicle. The vehicle can then automatically execute a strategy corresponding to the rescue update task to re-update the target components in a timely manner, thereby reducing problems such as vehicle power loss and battery over-discharge caused by the update failure.

[0045] The following describes technical solutions in the embodiments of the present invention with reference to the accompanying drawings. Obviously, the described embodiments are only a part, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort should fall within the scope of protection of the present invention. In addition, in the embodiments of the present application, the terms "first," "second," "third," "fourth," etc. are intended to distinguish between different objects and do not indicate a specific order. Furthermore, the terms "comprise," "have," and other variations are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, and may optionally further include unlisted steps or units, or may optionally further include other inherent steps or units of the process, method, product, or apparatus.

[0046] To facilitate understanding of this solution, the network architecture provided in the embodiment of the present application will be first described with reference to Fig. 1 in the embodiment of the present application. As shown in Fig. 1, the network architecture includes a server 101 and a first terminal device 102.

[0047] The server 101 communicates with the first terminal device 102 via a wireless communication link. The wireless communication link may be a mobile communication network (e.g., 2G / 3G / 4G / 5G / 6G network), a wireless local area network (WLAN), etc. In this embodiment of the present application, the wireless communication link is not limited.

[0048] The server 101 may be an over-the-air (OTA) server. The OTA server may be located in an electronic device having wireless communication capabilities and storage capabilities, or may be located in a virtual machine (VM) or a container on a cloud, which may be a cluster including multiple electronic devices.

[0049] In this embodiment of the present application, an example is described in which the first terminal device 102 is only a vehicle (e.g., a car, a truck, a motorcycle, a bus, a playground vehicle, a recreational vehicle, a trolley, a golf cart, etc.). In actual applications, the first terminal device may alternatively be a robot, a board, a lawn mower, a construction device, etc. This is not specifically limited here.

[0050] The network architecture is mainly used for software updates on the vehicle side, which mainly involves uploading the update software to the OTA center, then the OTA center wirelessly transmits the update software to the vehicle side, and the vehicle side automatically updates the software.

[0051] Optionally, the first terminal device 102 includes at least one of components such as a gateway (GW), a mobile data center (MDC), a human-machine interaction (HMI) system, a telematics control unit (TCU), a telematics box (Tbox), and an electronic control unit (ECU).

[0052] The GW is a core component in the vehicle's overall electronic and electrical architecture. It serves as a data exchange hub for the entire vehicle network and can route network data within different networks, such as the Controller Area Network (CAN), Local Interconnect Network (LIN), and Media Oriented System Transport (MOST) network. The MDC is the vehicle's intelligent in-vehicle computing platform. The MDC can be configured to realize the vehicle's autonomous driving functions. The HMI is the vehicle's information and entertainment system. The TCU and Tbox are mainly configured to communicate with the vehicle's external devices (e.g., mobile phones and background systems). The ECU is a vehicle-specific microcomputer controller. ECUs include, but are not limited to, the Vehicle Integrated / Integration Unit (VIU), Cockpit Domain Controller (CDC), and Vehicle Domain Controller (VDC).

[0053] Optionally, the Tbox includes a microprocessor unit (MPU) and a microcontroller unit (MCU) in the application layer. The MPU is mainly configured to implement application functions, and the MCU is mainly configured to control power management and access the vehicle CAN bus. The MPU and MCU can communicate with each other via a general-purpose input / output (GPIO) interface and a serial peripheral interface (SPI).

[0054] It may be understood that the structures shown in the embodiments of the present application do not constitute specific limitations on the first terminal device 102. In some other embodiments of the present application, the first terminal device 102 may include more or fewer components than those shown in the figures, combine some components, separate some components, or have a different component arrangement. The components in the figures may be implemented using hardware, software, or a combination of software and hardware. For example, the first terminal device 102 may further include at least one of a battery management system (BMS), a vehicle control unit (VCU), a body control module (BCM), a direct current-direct current (DCDC) module, an electronic stability controller (ESC), a global system for mobile communications (GSM), a generator control unit (GCU), an in-vehicle infotainment (IVI) system, an instrument controller (IC), etc.

[0055] Furthermore, the network architecture in this embodiment of the present application may include more servers, first terminal devices, and / or other devices, which is not specifically limited here.

[0056] For example, as shown in FIG. 2 , the network architecture may further include a second terminal device 103. A user may manage the first terminal device 102 through the second terminal device 103. For example, the user may perform an update process for the first terminal device 102 through the second terminal device 103. As another example, the user may send an update request to the server 101 through the second terminal device 103 and use the update request to update software in the first terminal device 102. As another example, the user may receive an update result from the server 101 through the second terminal device 103, and the update result may indicate that the first terminal device 102 has successfully updated its software.

[0057] Currently, when software in a vehicle needs to be installed or updated, it can be installed or updated by connecting to the cloud via OTA. Every time the vehicle sends an update request to the OTA server, the OTA server responds to the vehicle's update request and delivers a vehicle update package to the vehicle. The vehicle then performs the OTA update. If the vehicle's OTA update fails, a technician analyzes the cause of the update failure, creates an update task, and re-updates the vehicle based on the update task.

[0058] However, due to the uncertainty of when a technician will create the update task, it is possible that a vehicle's OTA update could fail for several hours, causing issues such as the vehicle losing power or the battery being deeply discharged.

[0059] To solve the above problems, an embodiment of the present application provides a device rescue method and a related device. After a vehicle fails to perform an update, the vehicle transmits first information including update failure information for multiple components to a server and then receives second information from the server for triggering a rescue update task, the rescue update task relating to a target component among the multiple components that should be re-updated. The vehicle then executes a strategy corresponding to the rescue update task to re-update the target component, and the strategy is used to restrict vehicle driving. The server can automatically determine the target component that should be re-updated based on the update failure information reported by the vehicle. Furthermore, the vehicle automatically executes the strategy corresponding to the rescue update task to re-update the target component in a timely manner, thereby reducing problems such as vehicle power loss and battery over-discharge caused by the update failure.

[0060] The following describes in detail the device rescue method provided in the embodiments of the present application with reference to the accompanying drawings. The method can be applied to vehicle OTA update scenarios, vehicle rescue scenarios, etc.

[0061] FIG. 3 illustrates an embodiment of a device rescue method provided in an embodiment of the present application. The method may be performed by a communication device or a component of the communication device (e.g., a processor, a chip, or a chip system). The communication device may include the server 101 shown in FIG. 1, the first terminal device 102 shown in FIG. 1, or the server 101 and the first terminal device 102 shown in FIG. 1 (i.e., the first terminal device and the server jointly perform the method). The method includes steps 301 to 307. Steps 301 to 307 will be described below using an example in which the first terminal device is a vehicle.

[0062] Step 301: The vehicle transmits first information to the server.

[0063] After the vehicle fails to perform a software update, the vehicle transmits first information to the server, and in response, the server receives the first information from the vehicle, the first information including update failure information for multiple components in the vehicle.

[0064] In this embodiment of the present application, there are multiple cases of the first information. The first information may be an update log of the vehicle, instruction information indicating that multiple components failed to update, or an indication of components that failed to update and components that were successfully updated, etc. This is not specifically limited here.

[0065] Components in the embodiment of the present application include a GW, an MDC, an HMI, a TCU, a T-box, an ECU, a BMS, a VCU, a BCM, a DCDC module, an ESC, a GSM, a GCU, an IVI, and an IC, as shown in FIG. 1 .

[0066] It may be understood that the vehicle may communicate directly with the server, or the vehicle may communicate indirectly with the server via one or more intermediate devices, which is not specifically limited herein.

[0067] Step 302: The server determines a target component to be re-updated from among the plurality of components based on the first information.

[0068] After the server receives the first information from the vehicle, the server determines, based on the first information, a target component to be re-updated from among the plurality of components.

[0069] In a possible implementation, the server determines the component that failed to be updated as the target component.

[0070] In another possible implementation, the server determines the key components that failed to be updated as target components. The key components can be understood as components related to the power and / or power supply of the vehicle, such as the BMS and the VCU.

[0071] Optionally, when the first information is an update log, after receiving the update log reported from the vehicle, the server analyzes the update failure status of the plurality of components in the update log and determines the component that has failed to be updated among the plurality of components as a target component. Alternatively, the component that has failed to be updated can also be understood as a target component that should be re-updated.

[0072] Optionally, the target component can be understood as a component whose update failure level is the target level, or as a primary component, which will be explained in detail in the next step 303 and will not be explained in detail here.

[0073] Step 303: The server determines a rescue update task for the target component.

[0074] After determining the target component to be re-updated, the server further determines a rescue update task for the target component. Alternatively, the rescue update task may be understood to be related to a target component to be re-updated among the multiple components.

[0075] Optionally, after determining the target component, the server first determines an update failure level of the target component, and then determines a relief update task based on the update failure level of the target component.

[0076] Optionally, there may be multiple update failure levels, and alternatively, the level may be understood as a severity. If a preset condition is met, a rescue update task corresponding to the target component is determined. Alternatively, it is understood that if a preset condition is met, a rescue update task corresponding to the target component is initiated. The preset condition is related to the update failure level. Specifically, if the failure level is the target level, it is determined to initiate a rescue update task for the target component. The level is related to failure information of the component. The failure information includes at least one of a failure category of the component, a flash failure phase of the component, and an impact caused by the flash failure phase of the component.

[0077] Additionally, the preset conditions may further include that the component that failed to be updated is a vehicle power component, a power supply component, or the like.

[0078] For example, step 302 and step 303 may alternatively be considered as a global decision process. Specifically, the server determines whether to initiate a rescue update task based on the OTA update failure level table and / or the major component and rescue configuration table. That is, the server may determine whether to initiate a rescue update task based on the following Table 1, or may determine whether to initiate a rescue update task based on Table 2, or may determine whether to initiate a rescue update task based on Tables 1 and 2 (e.g., first determine the update failure level based on Table 1, and then determine whether remote rescue is necessary based on Table 2). This is not specifically limited here.

[0079] For example, using the preset condition including a power component as an example, the vehicle OTA update failure classification is shown in Table 1. [Table 1]

[0080] In the example of Table 1, the target level is Level 5. The preconditions relate to a vehicle power check and / or power supply check. For example, the preconditions include at least one of a vehicle gear P gear check, a vehicle speed check, and an Electronic Parking Brake (EPB) status. A rollback can alternatively be understood as a flash. Level 6 corresponds to a long period in the flash fault phase, which can be set based on actual requirements, for example, more than 3 hours. A rescue is required can alternatively be understood as the vehicle needing to execute a strategy corresponding to the rescue. The strategy will be described in detail in the next step 305, and will not be described in detail here.

[0081] It should be understood that Table 1 is just an example of the classification of vehicle OTA update failures. In actual applications, there may be other methods for processing the classification of update failures, which are not specifically limited here.

[0082] For example, Table 2 shows a table of major components and relief configurations. [Table 2]

[0083] The BMS, VCU, BCM, DCDC, ESC, GSM and GW can alternatively be understood as main components.

[0084] It should be understood that Table 2 is merely an example of a table of main components and remedial configurations. In actual applications, the table of main components and remedial configurations may alternatively be in another format, which is not specifically limited here.

[0085] Step 304: The server transmits the second information to the vehicle.

[0086] After determining the rescue update task, the server transmits second information to the vehicle, and in response, the vehicle receives the second information from the server, which is used to trigger the rescue update task of the vehicle or to trigger the vehicle to execute a strategy corresponding to the rescue update task, and the strategy is used to restrict the driving of the vehicle.

[0087] Step 305: The vehicle executes the strategy corresponding to the relief update task.

[0088] After receiving the second information from the server, the vehicle executes a strategy of the relief update task, which is used to limit the driving of the vehicle.

[0089] Optionally, the strategy includes at least one of performing a high voltage turn-off operation and ignoring precondition checks for the vehicle.

[0090] Step 306: The vehicle re-updates the target component.

[0091] After receiving the second information from the server, the vehicle re-updates the target component.

[0092] Optionally, step 305 and step 306 may be understood as follows: after determining that a remote rescue task has been received, the vehicle executes a strategy based on the rescue task. Specifically, if the vehicle is in a high-voltage state, a high-voltage turn-off operation is performed to prevent driving operations in the update process, and the checks for P gear, vehicle speed, and EPB status, as well as the requirements for entering OTA mode, are ignored, and the update flash is directly performed.

[0093] Step 307: The vehicle sends the third information to the server. This step is optional.

[0094] Optionally, after re-updating the target component, the vehicle transmits third information to the server, and in response, the server receives third information from the vehicle, the third information indicating that the target component has been successfully updated or that the vehicle has been successfully updated.

[0095] In this embodiment of the present application, after a vehicle fails to update, the vehicle transmits first information including update failure information of multiple components to a server, and then receives second information from the server for triggering a rescue update task, the rescue update task relating to a target component among the multiple components that should be re-updated. Furthermore, the vehicle executes a strategy corresponding to the rescue update task to re-update the target component, and the strategy is used to restrict vehicle driving. The server can automatically determine the target component that should be re-updated based on the update failure information reported by the vehicle. Furthermore, because the vehicle automatically executes the strategy corresponding to the rescue update task to re-update the target component in a timely manner, problems such as vehicle power loss and battery over-discharge caused by the update failure can be reduced.

[0096] Alternatively, the method provided in this embodiment of the present application may be implemented based on a user's associated operation. Hereinafter, a user-participated device rescue method will be described with reference to FIG. 4. This process includes steps 401 to 410. Steps 401 to 410 will be described in detail below.

[0097] Step 401: Enable "automatic rescue in case of update failure" based on user operation. This step is optional.

[0098] Optionally, the vehicle may determine to enable the "automatic rescue in case of update failure" function based on a user operation. This function may be used to trigger subsequent processing. Specifically, this function may be used to trigger at least one of the following steps: a step of delivering a rescue update task to the server, a step of executing a strategy corresponding to the rescue update task by the vehicle, a step of re-updating the target component, a step of reporting the success of the re-update, etc.

[0099] In this embodiment of the present application, the user may enable the "automatic rescue in case of update failure" function through the vehicle's central control screen. Alternatively, the user may enable the "automatic rescue in case of update failure" function through an application on a mobile phone, etc. This is not specifically limited here.

[0100] The user enables the "automatic rescue in case of update failure" function through the vehicle's central control screen. As shown in FIG. 5, the application scenario of this example is on the vehicle's central control screen. The central control screen is shown in FIG. 6. The vehicle's central control screen may display a setting interface shown in FIG. 7 in response to a first user operation 601. The user may also enable the "automatic rescue in case of update failure" function through a second operation 701. The first operation 601 may be an operation performed by the user by tapping a setting on the central control screen, and the second operation 702 may be an operation performed by the user by tapping an enable button for the "automatic rescue in case of update failure" function. It should be understood that the above operations are merely examples. In actual applications, the "automatic rescue in case of update failure" function may be enabled by voice, a physical button, or the like.

[0101] For example, the user enables the "automatic rescue in case of update failure" function through an application on the mobile phone. In response to the user's operation, the mobile phone displays the rescue setting interface shown in Fig. 8. Furthermore, the user may enable the "automatic rescue in case of update failure" function through a third operation 801.

[0102] Step 402: The vehicle transmits first information to the server.

[0103] Step 403: The server determines a target component to be re-updated from among the plurality of components based on the first information.

[0104] Step 404: The server determines a rescue update task for the target component.

[0105] Step 405: The server transmits the second information to the vehicle.

[0106] Steps 402-405 in this embodiment of the present application are similar to steps 301-304 in the previous embodiment, and the details will not be described again here.

[0107] Step 406: The server sends the first prompt information to the mobile phone.

[0108] After determining the rescue update task for the target component, the server sends first prompt information to the mobile phone, which prompts the user that an automatic rescue update should be performed on the vehicle.

[0109] Optionally, the user has already decided to enable the “automatic rescue when update failure” function in step 401, so the user does not need to perform a decision operation in this step. Of course, if step 401 does not exist, the first prompt information in this step may be used by the user to decide whether to enable the “automatic rescue when update failure” function.

[0110] Step 407: The vehicle executes the strategy corresponding to the relief update task.

[0111] Step 408: The vehicle re-updates the target component.

[0112] Step 409: The vehicle transmits the third information to the server.

[0113] Steps 407-409 in this embodiment of the present application are similar to steps 305-307 in the previous embodiment, and the details will not be described again here.

[0114] Step 410: The server sends the fourth information to the mobile phone.

[0115] After determining that the vehicle has been successfully re-updated, the server sends fourth information to the mobile phone. In response, the mobile phone receives the fourth information sent by the server. The fourth information prompts the user that the vehicle has been successfully re-updated.

[0116] Also, in this embodiment of the present application, there is no time order relationship between the steps. For example, step 406 may be performed during step 405. Step 401 may be performed after step 404, etc. This is not specifically limited here.

[0117] In this embodiment of the present application, a user can enable the "automatic rescue due to update failure" function by operating the vehicle's central control screen or a mobile phone application, and rescue the vehicle after an OTA update failure based on a strategy corresponding to the rescue update task. Furthermore, since the user is aware of the automatic rescue, they do not need to worry about whether they can drive normally if the update fails. Furthermore, the server automatically and accurately identifies the major component whose update failed and automatically delivers a rescue update task within minutes of the update failure. This prevents battery over-discharge and driving problems caused by a major component update failure. By adding a rescue task scenario identification function to the vehicle and optimizing the update prerequisite determination strategy, the vehicle can perform the update and installation after receiving the rescue task. This prevents battery over-discharge and driving problems caused by a major component update failure.

[0118] The above has described the device rescue method in the embodiment of the present application. The following describes the device in the embodiment of the present application. Referring to FIG. 9, the first terminal device in the embodiment of the present application includes: A sending unit 901 configured to send first information to a server, the first information including update failure information of a plurality of components in a first terminal device; a receiving unit 902 configured to receive second information from a server, the second information being used to trigger a rescue update task of the first terminal device, the rescue update task being related to a target component to be re-updated among the plurality of components; A processing unit 903 configured to execute a strategy corresponding to the rescue update task, the strategy being used to restrict the operation of the first terminal device.

[0119] The processing unit 900 is further configured to re-update the target component.

[0120] Optionally, the strategy includes at least one of performing a high voltage turn-off operation and ignoring a precondition check for the first terminal device, the preconditions including at least one of a power check for the first terminal device and a power supply check for the terminal device.

[0121] Optionally, the target component includes at least one of a power component of the first terminal device and a power supply component of the first terminal device.

[0122] Optionally, the sending unit 901 is further configured to send third information to the server, where the third information indicates that the target component has been successfully updated.

[0123] In this embodiment, the operations performed by the units of the first terminal device are similar to those described in the embodiment shown in Figures 1 to 8. The details will not be described again here.

[0124] In this embodiment, after the vehicle fails to update, the transmitting unit 91 transmits first information including update failure information of multiple components to the server. The receiving unit 902 then receives second information from the server for triggering a rescue update task, where the rescue update task is related to a target component among the multiple components that should be re-updated. Furthermore, the vehicle executes a strategy corresponding to the rescue update task to re-update the target component, and the strategy is used to restrict vehicle driving. The server can automatically determine the target component that should be re-updated based on the update failure information reported by the vehicle. Furthermore, the vehicle automatically executes a strategy corresponding to the rescue update task to re-update the target component in a timely manner, thereby reducing problems such as vehicle power loss and battery over-discharge caused by the update failure.

[0125] Referring to FIG. 10, the server embodiment in the present application includes: a receiving unit 1001 configured to receive first information from a first terminal device, the first information including update failure information of a plurality of components in the first terminal device; a processing unit 1002 configured to determine a target component to be re-updated among the plurality of components based on the first information, the processing unit 1002 being further configured to determine a rescue update task for the target component; and a transmitting unit 1003 configured to transmit second information to a first terminal device, the second information being used to trigger the first terminal device to execute a strategy corresponding to the rescue update task, the strategy being used to limit the operation of the first terminal device.

[0126] Optionally, the processing unit 1002 is further configured to determine an updated failure level of the target component. The processing unit 1002 is specifically configured to determine a rescue update task based on the updated failure level when a preset condition is satisfied, where the preset condition includes: the updated failure level being a target level.

[0127] Optionally, the preset condition further includes that the target component is at least one of a power component of the first terminal device and a power supply component of the first terminal device.

[0128] Optionally, the receiving unit 1001 is further configured to receive third information from the first terminal device, where the third information indicates that the target component has been successfully updated.

[0129] Optionally, the sending unit 1003 is further configured to send first prompt information to the second terminal device, the first prompt information indicating that the server will deliver a rescue update task to the second terminal device, and the sending unit 1003 is further configured to send second prompt information to the second terminal device, the second prompt information indicating that the first terminal device has been successfully updated.

[0130] Optionally, the receiving unit 11 is further configured to receive activation information from the second terminal device, where the activation information is used by the user to decide to activate the function of the rescue update task.

[0131] In this embodiment, the operations performed by the units of the server are similar to those described in the embodiment shown in Figures 1 to 8. The details will not be described again here.

[0132] In this embodiment, after a vehicle fails to update, the receiving unit 1001 receives update failure information for multiple components transmitted by the vehicle. The processing unit 1002 determines a rescue update task based on the actual failure information, where the rescue update task is related to a target component among the multiple components that should be re-updated. Furthermore, the vehicle executes a strategy corresponding to the rescue update task to re-update the target component, and the strategy is used to restrict vehicle driving. The server can automatically determine the target component that should be re-updated based on the update failure information reported by the vehicle. Furthermore, the vehicle automatically executes a strategy corresponding to the rescue update task to re-update the target component in a timely manner, thereby reducing problems such as vehicle power loss and battery over-discharge caused by the update failure.

[0133] 11 is a diagram of another server architecture according to the present application. The server may include a processor 1101, a memory 1102, and a communication interface 1103. The processor 1101, the memory 1102, and the communication interface 1103 are interconnected via lines. The memory 1102 stores program instructions and data.

[0134] Memory 1102 stores program instructions and data corresponding to the steps performed by the server in the implementations shown in FIGS.

[0135] The processor 1101 is configured to be executed by the server and to perform the steps shown in any one of the embodiments shown in FIGS.

[0136] The communication port 1103 can be configured to send and receive data, and is configured to perform the steps associated with obtaining, sending, and receiving in any one of the embodiments shown in FIGS.

[0137] In one implementation, the server may include more or fewer components than those shown in Figure 11. This is merely an exemplary illustration and is not intended to be limiting in this application.

[0138] In some embodiments provided herein, it should be understood that the disclosed systems, devices, and methods may be implemented in other ways. For example, the described device embodiments are merely examples. For example, the division into units is merely a logical functional division, and other divisions may occur in actual implementation. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not implemented. Furthermore, the shown or discussed mutual couplings or direct couplings or communication connections may be implemented through some interfaces. Indirect couplings or communication connections between devices or units may be implemented electronically, mechanically, or in other forms.

[0139] The units described as separate components may or may not be physically separated. The parts shown as units may or may not be physical units, and may be located in one place or distributed among multiple network units. Some or all of the units may be selected based on actual requirements to achieve the purpose of the solution of the embodiment.

[0140] Furthermore, the functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may exist physically alone, or two or more units may be integrated into one unit, and all or part of the integrated units may be implemented by using software, hardware, firmware, or any combination thereof.

[0141] When software is used to implement an integrated unit, all or a portion of the integrated unit may be implemented in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or a portion of the procedures or functions according to the embodiments of the present invention are generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or another programmable device. The computer instructions may be stored on a computer-readable storage medium or transmitted from a computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions may be transmitted from a website, computer, server, or data center to another website, computer, server, or data center via a wired (e.g., coaxial cable, optical fiber, or digital subscriber line (DSL)) or wireless (e.g., infrared, radio, or microwave) method. The computer-readable storage medium may be a data storage device, such as any available medium accessible by a computer, or a server or data center integrating one or more available media. The usable medium may be a magnetic medium (e.g., a floppy disk, a hard disk, or a magnetic tape), an optical medium (e.g., a DVD), a semiconductor medium (e.g., a solid-state drive (SSD)), or the like.

[0142] In the specification, claims, and accompanying drawings of this application, the terms "first," "second," etc. are intended to distinguish between similar objects and do not necessarily indicate a particular order or sequence. Terms used in this manner should be understood to be interchangeable under appropriate circumstances. This is merely a method of identification used when objects having the same attributes are described in embodiments of this application. Furthermore, the terms "comprise," "have," and any other variations are meant to cover a non-exclusive inclusion; a process, method, system, product, or apparatus comprising a series of units is not necessarily limited to those units and may include other units not expressly listed or inherent in such process, method, product, or apparatus.

Claims

1. 1. A device rescue method, the method being applied to a first terminal device, the method comprising: transmitting first information to a server, the first information including update failure information of a plurality of components in the first terminal device; receiving second information from the server, the second information being used to trigger a rescue update task of the first terminal device, the rescue update task relating to a target component to be re-updated among the plurality of components; Executing a strategy corresponding to the rescue update task, the strategy being used to limit the operation of the first terminal device; re-updating the target component; A method comprising:

2. 2. The method of claim 1, wherein the strategy includes at least one of performing a high voltage turn-off operation and ignoring a precondition check for the first terminal device, the preconditions including at least one of a power check for the first terminal device and a power supply check for the terminal device.

3. The method of claim 1 or 2, wherein the target component includes at least one of a power component of the first terminal device and a power supply component of the first terminal device.

4. After re-updating the target component, the method includes: sending third information to the server, the third information indicating that the target component has been successfully updated; The method of any one of claims 1 to 3, further comprising:

5. 1. A device rescue method, the method being applied to a server, the method comprising: receiving first information from a first terminal device, the first information including update failure information of a plurality of components in the first terminal device; determining a target component to be re-updated among the plurality of components based on the first information; determining a rescue update task for the target component; sending second information to the first terminal device, the second information being used to trigger the first terminal device to execute a strategy corresponding to the rescue update task, the strategy being used to limit the operation of the first terminal device; A method comprising:

6. Before determining a rescue update task for the target component, the method includes: determining an updated fault level for the target component; The step of determining a rescue update task for the target component includes:

6. The method of claim 5, further comprising: determining the relief update task based on the update failure level if a preset condition is met, the preset condition including the update failure level being a target level.

7. The method of claim 6 , wherein the preset condition includes that the target component includes at least one of a power component of the first terminal device and a power supply component of the first terminal device.

8. After transmitting the second information to the first terminal device, the method further comprises: receiving third information from the first terminal device, the third information indicating that the target component has been successfully updated; The method of any one of claims 5 to 7, further comprising:

9. Before determining a rescue update task for the target component among the plurality of components based on the first information, the method further comprises: sending first prompt information to a second terminal device, the first prompt information indicating that the server intends to distribute the rescue update task to the second terminal device; After receiving the third information from the first terminal device, the method further comprises:

9. The method of claim 8, further comprising the step of sending second prompt information to the second terminal device, the second prompt information indicating that the first terminal device has been successfully updated.

10. Before determining a rescue update task for the target component among the plurality of components based on the first information, the method further comprises: The method of any one of claims 5 to 9, further comprising the step of receiving activation information from the second terminal device, the activation information being used by a user to decide to activate the function of the rescue update task.

11. A first terminal device, the first terminal device comprising: a sending unit configured to send first information to a server, the first information including update failure information of a plurality of components in the first terminal device; a receiving unit configured to receive second information from the server, the second information being used to trigger a rescue update task of the first terminal device, the rescue update task being related to a target component to be re-updated among the plurality of components; a processing unit configured to execute a strategy corresponding to the rescue update task, the strategy being used to limit the operation of the first terminal device; Including, The apparatus, wherein the processing unit is further configured to re-update the target component.

12. 12. The device of claim 11, wherein the strategy includes at least one of performing a high voltage turn-off operation and ignoring a precondition check for the first terminal device, the preconditions including at least one of a power check for the first terminal device and a power supply check for the terminal device.

13. The device according to claim 11 or 12, wherein the target component comprises at least one of a power component of the first terminal device and a power supply component of the first terminal device.

14. The apparatus of any one of claims 11 to 13, wherein the sending unit is further configured to send third information to the server, the third information indicating that the target component has been successfully updated.

15. A server, the server comprising: a receiving unit configured to receive first information from a first terminal device, the first information including update failure information of a plurality of components in the first terminal device; a processing unit configured to determine a target component to be re-updated among the plurality of components based on the first information, the processing unit further configured to determine a rescue update task for the target component; a sending unit configured to send second information to the first terminal device, the second information being used to trigger the first terminal device to execute a strategy corresponding to the relief update task, the strategy being used to limit the operation of the first terminal device; Server containing.

16. the processing unit is further configured to determine an updated impairment level for the target component; 16. The server of claim 15, wherein the processing unit is specifically configured to determine the relief update task based on the update failure level when a preset condition is met, and the preset condition includes: the update failure level being a target level.

17. The server of claim 16 , wherein the preset condition includes that the target component includes at least one of a power component of the first terminal device and a power supply component of the first terminal device.

18. The server of any one of claims 15 to 17, wherein the receiving unit is further configured to receive third information from the first terminal device, the third information indicating that the target component has been successfully updated.

19. The sending unit is further configured to send first prompt information to a second terminal device, the first prompt information indicating that the server will distribute the rescue update task to the second terminal device; 20. The server of claim 18, wherein the sending unit is further configured to send second prompt information to the second terminal device, the second prompt information indicating that the first terminal device has been successfully updated.

20. The server of any one of claims 15 to 19, wherein the receiving unit is further configured to receive activation information from the second terminal device, and the activation information is used by a user to decide to activate the function of the rescue update task.

21. A first terminal device including a processor, the processor coupled to a memory, the memory configured to store a program or instructions, and when the program or the instructions are executed by the processor, the first terminal device is enabled to perform the method of any one of claims 1 to 4.

22. A server comprising a processor, the processor coupled to a memory, the memory configured to store a program or instructions, the program or instructions being executed by the processor to enable the server to perform the method of any one of claims 5 to 10.

23. A communication system, the communication system comprising a first terminal device according to claim 21 and / or a server according to claim 22.

24. A vehicle including the first terminal device according to any one of claims 11 to 14.

25. A computer storage medium comprising computer instructions, which when executed on a terminal device, enable the terminal device to carry out the method of any one of claims 1 to 10.

26. A computer program product, when said computer program product is run on a computer, enabling said computer to carry out the method according to any one of claims 1 to 10.

Images