Upgrading method and related apparatus

Abstract

An upgrading method and a related apparatus, for use in the technical field of connected vehicles. The method is used in a vehicle, the vehicle comprising a first component. In case of first component malfunction, the first component is upgraded according to first policy information, the first policy information being used for instructing to ignore the results of N upgrade condition checks, or the first policy information being used for instructing to ignore execution of the N upgrade condition checks; in case of no first component malfunction, M upgrade condition checks are executed according to second policy information and, if the M upgrade condition checks are successful, the first component is upgraded. N and M are integers greater than 0. In the present application, when an abnormality occurs in a core component (namely the first component) of the vehicle, a vehicle end actively identifies abnormal state information and generates the first policy information to rescue the core component; such an automatic rescue mode not requiring human involvement reduces operation costs while improving rescue efficiency and enhancing the user experience.

Description

Upgrading method and related device

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office of China on October 30, 2023, with application number 202311437157.6 and application name “Upgrading Method and Related Devices”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of connected vehicle technology, and in particular to an upgrading method and related devices. Background Art

[0003] As connected vehicle technology matures and services improve, over-the-air (OTA) technology, a remote upgrade method, is also gaining popularity on in-vehicle terminals. Existing OTA upgrade solutions can cause core components to become "bricked" if the upgrade fails. This requires operator intervention, such as using a tow truck or local flashing to restore the vehicle. This approach is inefficient and offers a poor user experience.

[0004] Summary of the Invention

[0005] The embodiments of the present application provide an upgrade method and related devices, which can improve the efficiency of vehicle rescue and help enhance user experience.

[0006] In a first aspect, an embodiment of the present application provides an upgrade method, which is executed by a terminal. The terminal can be the terminal itself, or a unit, circuit, or module (such as a chip) in the terminal with corresponding functions. This application is not limited to this. For example, this application uses the terminal as a vehicle for schematic illustration. The vehicle includes a first component. The method includes:

[0007] In the event of a failure of the first component, upgrading the first component according to first policy information, where the first policy information is used to indicate ignoring results of N upgrade condition checks, or the first policy information is used to indicate ignoring execution of the N upgrade condition checks, where N is an integer greater than 0;

[0008] In a case where the first component is not faulty, M upgrade condition checks are performed according to the second policy information, where M is an integer greater than 0; in a case where the M upgrade condition checks are passed, the first component is upgraded, wherein passing the first upgrade condition check includes the result of the first upgrade condition check being successful, and the first upgrade condition check is any one of the M upgrade condition checks.

[0009] In an embodiment of the present application, when a core component of the vehicle (i.e., the first component) is abnormal, the vehicle proactively identifies the abnormal status information and generates first strategy information to rescue / upgrade the core component. This automatic rescue method that does not require human intervention can reduce operating costs, while also helping to improve rescue efficiency and enhance user experience. It should be understood that rescuing the core component based on the first strategy information can simplify the pre-upgrade condition judgment and related processing procedures to complete the core component flashing.

[0010] In a possible implementation manner, the first policy information is associated with the second policy information, the second policy information comes from a server, and the first policy information is determined by the vehicle or pre-configured in the vehicle.

[0011] In this implementation, the first policy information can be policy information automatically generated by the vehicle when a core component fails, or policy information pre-configured in the vehicle that is read. The first policy information indicates an emergency rescue task. Therefore, the vehicle completes the rescue of the core component based on the first policy information determined by itself. This automatic diagnosis and identification and automatic rescue and repair method is conducive to improving rescue efficiency and enhancing user experience. The second policy information is the policy information sent by the server to the vehicle when the core component does not fail. The second policy information indicates a normal OTA upgrade task. Therefore, the vehicle can complete the OTA upgrade task based on the second policy information sent by the receiving server.

[0012] In one possible implementation, the method further includes:

[0013] Acquiring abnormal status information of the first component;

[0014] determining a first abnormality level according to the abnormal state information, where the first abnormality level belongs to one of a plurality of abnormality levels, where the plurality of abnormality levels are used to describe the severity of the fault;

[0015] When the first component fails, upgrading the first component according to the first policy information includes:

[0016] When the first abnormality level meets a preset condition, the first component is upgraded according to the first policy information.

[0017] In this implementation, abnormal status information of the vehicle (or various components in the vehicle) can be obtained, and the corresponding abnormality level can be determined based on the obtained abnormal status information. Then, based on the relationship between the abnormality level and the preset conditions, policy information can be selected to execute the upgrade task. Taking the abnormal status information of the first component as an example, when the abnormal status information of the first component is obtained and, based on the abnormal status information of the first component, the corresponding first abnormality level is determined to meet the preset conditions, the first component can be upgraded according to the first policy information.

[0018] In a possible implementation, the multiple abnormality levels are positively correlated with the severity of the fault;

[0019] The first abnormality level meets the preset conditions, including:

[0020] The first abnormality level is not lower than a level threshold.

[0021] In this implementation, multiple anomaly levels are positively correlated with fault severity, meaning higher anomaly levels indicate more severe faults. When a first anomaly level is greater than or equal to a threshold, the first component is upgraded according to the first policy information, enabling automatic rescue and repair of the vehicle's core components when an anomaly occurs.

[0022] In one possible implementation, the multiple abnormality levels are negatively correlated with the fault severity;

[0023] The first abnormality level meets the preset conditions, including:

[0024] The first abnormality level is not higher than a level threshold.

[0025] In this implementation, multiple anomaly levels are negatively correlated with fault severity, meaning lower anomaly levels indicate more severe faults. When a first anomaly level is lower than or equal to a threshold, the first component is upgraded according to the first policy information, enabling automatic rescue and repair of the vehicle's core components when an anomaly occurs.

[0026] In one possible embodiment, the first component is a power-related component of the vehicle. In other words, the core component of the vehicle is the power-related component of the vehicle. It should be understood that since a failure of a power-related component of a vehicle will affect the normal use of the entire vehicle, emergency rescue is required.

[0027] In one possible implementation, the power-related components include one or more of the following:

[0028] Battery management system (BMS), microcontroller unit (MCU), or power distribution unit (PDU).

[0029] Optionally, the power-related component may also be a keyless entry and start system (passive entry passive start, PEPS), etc., which is not limited in this application.

[0030] In one possible implementation, the N upgrade condition checks include one or more of the following:

[0031] Pull the high-voltage signal to check, pull the vehicle ignition signal to check, check the vehicle's power battery percentage, check the vehicle's speed, check the vehicle's gear position, check the vehicle's ignition status, check the vehicle's on-board diagnostic interface status, check whether the vehicle allows whole-vehicle upgrade or whole-vehicle flashing, check the vehicle's handbrake status, check the vehicle's fast charging gun connection status, check the vehicle's charging gun connection status, check the vehicle's fuel filler cap status, check the vehicle's battery percentage, or notify the vehicle to enter upgrade mode.

[0032] In a possible implementation, the upgrading the first component according to the first policy information includes:

[0033] The first component is upgraded at a first moment according to the first policy information.

[0034] In a possible implementation, the upgrading the first component according to the first policy information at the first moment includes:

[0035] When the user is not in the car, the first component is upgraded according to the first policy information at the first moment.

[0036] In this implementation, when the user is not in the vehicle, the vehicle can upgrade the first component according to the first strategy information at the scheduled time (for example, the first moment), which is more in line with the actual scenario and makes the applicability of this solution higher.

[0037] In a possible implementation, before upgrading the first component according to the first policy information at the first moment, the method further includes:

[0038] releasing a first vehicle control signal, where the first vehicle control signal is a signal associated with executing the M upgrade condition checks;

[0039] A second vehicle control signal is activated, where the second vehicle control signal is a signal associated with the first strategy information.

[0040] In this implementation, the vehicle releases the first vehicle control signal before the scheduled time, which helps save energy. In addition, by pulling the second vehicle control signal, it is convenient to directly upgrade the first component according to the first strategy information after the first moment arrives, which helps improve rescue efficiency.

[0041] In a possible implementation manner, the second vehicle control signal is included in the first vehicle control signal.

[0042] In a possible implementation, the upgrading the first component according to the first policy information includes:

[0043] When the user is in the car, the first component is upgraded according to the first policy information.

[0044] In this implementation mode, when the user is in the car, the first component needs to be upgraded directly according to the first strategy information. This is conducive to implementing vehicle rescue as soon as possible in the scenario where the user needs to use the car, meeting the user's car needs and improving the user experience.

[0045] In a possible implementation manner, before upgrading the first component according to the first policy information, the method further includes:

[0046] Obtaining a first user instruction;

[0047] Based on the first user instruction, the first component is upgraded according to the first policy information.

[0048] Under this implementation method, the user can input / select an operation instruction (such as a first user instruction) on the user interface / visual interface. The first user instruction is used to trigger the vehicle to upgrade the first component according to the first strategy information. This method of triggering upgrades based on user instructions enhances user participation, which in turn helps to improve user satisfaction.

[0049] In a second aspect, an embodiment of the present application provides an upgrade method, which is executed by a server. The server can be the server itself, or a unit, circuit, or module (such as a chip) in the server with corresponding functions. This application is not limited to this. For example, this application is schematically described with the server as the execution subject. The method includes:

[0050] generating second strategy information;

[0051] sending the second strategy information to the vehicle;

[0052] The vehicle includes a first component, the second policy information is associated with M upgrade condition checks, the M upgrade condition checks are upgrade condition checks corresponding to when the first component is not faulty, the second policy information is associated with the first policy information, the first policy information is upgrade policy information corresponding to when the first component is faulty, the first policy information is used to indicate ignoring the results of the N upgrade condition checks, or the first policy information is used to indicate ignoring the execution of the N upgrade condition checks, M is an integer greater than 0, and N is an integer greater than 0.

[0053] In an embodiment of the present application, the second policy information is the policy information sent by the server to the vehicle when the core component (such as the first component) has not failed. The second policy information has the meaning of indicating a normal OTA upgrade task. Therefore, the vehicle can complete the OTA upgrade task based on the second policy information sent by the receiving server.

[0054] In a possible implementation manner, the first strategy information is determined by the vehicle or preconfigured in the vehicle.

[0055] In a possible implementation manner, the first component is a power-related component of the vehicle.

[0056] In one possible implementation, the power-related components include one or more of the following:

[0057] BMS, MCU, or PDU.

[0058] In one possible implementation, the N upgrade condition checks include one or more of the following:

[0059] Pull the high-voltage signal to check, pull the vehicle ignition signal to check, check the vehicle's power battery percentage, check the vehicle's speed, check the vehicle's gear position, check the vehicle's ignition status, check the vehicle's on-board diagnostic interface status, check whether the vehicle allows whole-vehicle upgrade or whole-vehicle flashing, check the vehicle's handbrake status, check the vehicle's fast charging gun connection status, check the vehicle's charging gun connection status, check the vehicle's fuel filler cap status, check the vehicle's battery percentage, or notify the vehicle to enter upgrade mode.

[0060] In a third aspect, an embodiment of the present application provides an upgrade device, which may be a vehicle. The vehicle includes a first component, and the device includes:

[0061] a processing unit, configured to, in the event that the first component fails, upgrade the first component according to first policy information, wherein the first policy information is used to instruct to ignore results of N upgrade condition checks, or the first policy information is used to instruct to ignore execution of the N upgrade condition checks, where N is an integer greater than 0;

[0062] The processing unit is configured to perform M upgrade condition checks according to the second policy information when the first component is not faulty, where M is an integer greater than 0; the processing unit is configured to upgrade the first component when the M upgrade condition checks are passed, wherein passing the first upgrade condition check includes the result of the first upgrade condition check being successful, and the first upgrade condition check is any one of the M upgrade condition checks.

[0063] In a possible implementation manner, the first policy information is associated with the second policy information, the second policy information comes from a server, and the first policy information is determined by the vehicle or pre-configured in the vehicle.

[0064] In a possible implementation, the processing unit is further configured to:

[0065] Acquiring abnormal status information of the first component;

[0066] determining a first abnormality level according to the abnormal state information, where the first abnormality level belongs to one of a plurality of abnormality levels, where the plurality of abnormality levels are used to describe the severity of the fault;

[0067] When the first component fails, the processing unit is configured to upgrade the first component according to the first policy information:

[0068] When the first abnormality level meets a preset condition, the first component is upgraded according to the first policy information.

[0069] In a possible implementation, the multiple abnormality levels are positively correlated with the severity of the fault;

[0070] The first abnormality level meets the preset conditions, including:

[0071] The first abnormality level is not lower than a level threshold.

[0072] In one possible implementation, the multiple abnormality levels are negatively correlated with the fault severity;

[0073] The first abnormality level meets the preset conditions, including:

[0074] The first abnormality level is not higher than a level threshold.

[0075] In a possible implementation manner, the first component is a power-related component of the vehicle.

[0076] In one possible implementation, the power-related components include one or more of the following:

[0077] BMS, MCU, or PDU.

[0078] In one possible implementation, the N upgrade condition checks include one or more of the following:

[0079] Pull the high-voltage signal to check, pull the vehicle ignition signal to check, check the vehicle's power battery percentage, check the vehicle's speed, check the vehicle's gear position, check the vehicle's ignition status, check the vehicle's on-board diagnostic interface status, check whether the vehicle allows whole-vehicle upgrade or whole-vehicle flashing, check the vehicle's handbrake status, check the vehicle's fast charging gun connection status, check the vehicle's charging gun connection status, check the vehicle's fuel filler cap status, check the vehicle's battery percentage, or notify the vehicle to enter upgrade mode.

[0080] In a possible implementation, the upgrading the first component according to the first policy information includes:

[0081] The first component is upgraded at a first moment according to the first policy information.

[0082] In a possible implementation, the upgrading the first component according to the first policy information at the first moment includes:

[0083] When the user is not in the car, the first component is upgraded according to the first policy information at the first moment.

[0084] In a possible implementation, before upgrading the first component according to the first policy information at the first moment, the processing unit is further configured to:

[0085] releasing a first vehicle control signal, where the first vehicle control signal is a signal associated with executing the M upgrade condition checks;

[0086] A second vehicle control signal is activated, where the second vehicle control signal is a signal associated with the first strategy information.

[0087] In a possible implementation manner, the second vehicle control signal is included in the first vehicle control signal.

[0088] In a possible implementation manner, when the first component is upgraded according to the first policy information, the processing unit is configured to:

[0089] When the user is in the car, the first component is upgraded according to the first policy information.

[0090] In a possible implementation, before upgrading the first component according to the first policy information, the processing unit is configured to:

[0091] Obtaining a first user instruction;

[0092] Based on the first user instruction, the first component is upgraded according to the first policy information.

[0093] Regarding the technical effects brought about by the third aspect and any possible implementation method, please refer to the introduction of the technical effects corresponding to the first aspect and the corresponding implementation method.

[0094] In a fourth aspect, an embodiment of the present application provides an upgrade device, which may be a server, comprising:

[0095] a processing unit, configured to generate second policy information;

[0096] a transceiver unit, configured to send the second strategy information to the vehicle;

[0097] The vehicle includes a first component, the second policy information is associated with M upgrade condition checks, the M upgrade condition checks are upgrade condition checks corresponding to when the first component is not faulty, the second policy information is associated with the first policy information, the first policy information is upgrade policy information corresponding to when the first component is faulty, the first policy information is used to indicate ignoring the results of the N upgrade condition checks, or the first policy information is used to indicate ignoring the execution of the N upgrade condition checks, M is an integer greater than 0, and N is an integer greater than 0.

[0098] In a possible implementation manner, the first strategy information is determined by the vehicle or preconfigured in the vehicle.

[0099] In a possible implementation manner, the first component is a power-related component of the vehicle.

[0100] In one possible implementation, the power-related components include one or more of the following:

[0101] BMS, MCU, or PDU.

[0102] In one possible implementation, the N upgrade condition checks include one or more of the following:

[0103] Pull the high-voltage signal to check, pull the vehicle ignition signal to check, check the vehicle's power battery percentage, check the vehicle's speed, check the vehicle's gear position, check the vehicle's ignition status, check the vehicle's on-board diagnostic interface status, check whether the vehicle allows whole-vehicle upgrade or whole-vehicle flashing, check the vehicle's handbrake status, check the vehicle's fast charging gun connection status, check the vehicle's charging gun connection status, check the vehicle's fuel filler cap status, check the vehicle's battery percentage, or notify the vehicle to enter upgrade mode.

[0104] Regarding the technical effects brought about by the fourth aspect and any possible implementation method, please refer to the introduction of the technical effects corresponding to the second aspect and the corresponding implementation method.

[0105] Optionally, in the upgrading device described in any one of the third to fourth aspects and any possible implementation manner:

[0106] In one design, the upgrade device is a communication device. When the upgrade device is a communication device, the transceiver unit may be a transceiver or an input / output interface; the processing unit may be at least one processor. Alternatively, the transceiver may be a transceiver circuit. Alternatively, the input / output interface may be an input / output circuit.

[0107] In another design, the upgrade device is a chip (system) or circuit used in a communication device. When the upgrade device is a chip (system) or circuit used in a communication device, the transceiver unit can be a communication interface (input / output interface), interface circuit, output circuit, input circuit, pin, or related circuit on the chip (system) or circuit; the processing unit can be at least one processor, processing circuit, or logic circuit.

[0108] In a fifth aspect, embodiments of the present application provide an upgrade device, comprising a processor. The processor is coupled to a memory and can be configured to execute instructions in the memory to implement the method of any of the first and second aspects described above, and any possible implementation thereof. Optionally, the upgrade device further comprises a memory. Optionally, the upgrade device further comprises a communication interface, the processor being coupled to the communication interface.

[0109] In a sixth aspect, embodiments of the present application provide an upgrade device, comprising: a logic circuit and a communication interface. The communication interface is configured to receive or send information; the logic circuit is configured to receive or send information via the communication interface, so that the upgrade device executes the method of any of the first and second aspects above, and any possible implementation thereof.

[0110] In the seventh aspect, an embodiment of the present application provides a computer-readable storage medium, which is used to store a computer program (also referred to as code, or instructions); when the computer program is run on a computer, the method of any one of the above-mentioned first to second aspects and any possible implementation method is implemented.

[0111] In an eighth aspect, an embodiment of the present application provides a computer program product, comprising: a computer program (also referred to as code, or instructions); when the computer program is run, it enables the computer to execute any one of the above-mentioned first to second aspects and any possible implementation method.

[0112] In a ninth aspect, an embodiment of the present application provides a chip, comprising a processor configured to execute instructions. When the processor executes the instructions, the chip performs the method of any one of the first and second aspects and any possible implementation methods described above. Optionally, the chip further comprises a communication interface configured to receive or send signals.

[0113] In the tenth aspect, an embodiment of the present application provides a vehicle end, which includes at least one upgrade device as described in the third aspect, or the upgrade device as described in the fourth aspect, or the upgrade device as described in the fifth aspect, or the upgrade device as described in the sixth aspect, or the chip as described in the ninth aspect.

[0114] In the eleventh aspect, an embodiment of the present application provides a system, which includes a vehicle and a server, wherein the vehicle is used to execute the method of the above-mentioned first aspect and any possible implementation method, and the server is used to execute the method of the above-mentioned second aspect and any possible implementation method.

[0115] In addition, in the process of executing the method described in any aspect of the first aspect to the second aspect and any possible implementation method, the process of sending information and / or receiving information in the above method can be understood as the process of the processor outputting information and / or the process of the processor receiving input information. When outputting information, the processor can output the information to the transceiver (or communication interface, or sending module) so that it can be transmitted by the transceiver. After the information is output by the processor, it may also need to undergo other processing before it reaches the transceiver. Similarly, when the processor receives input information, the transceiver (or communication interface, or sending module) receives the information and inputs it into the processor. Furthermore, after the transceiver receives the information, the information may need to undergo other processing before it is input into the processor.

[0116] Based on the above principles, for example, the sending of information mentioned in the above method can be understood as the processor outputting information. For another example, the receiving of information can be understood as the processor receiving input information.

[0117] Optionally, for the operations such as transmission, sending and receiving involved in the processor, if there is no special explanation, or if they do not conflict with their actual functions or internal logic in the relevant description, they can be more generally understood as processor output, reception, input and other operations.

[0118] Optionally, in the process of executing the method described in any aspect of the first to second aspects and any possible implementation method, the processor may be a processor specifically used to execute these methods, or a processor that executes these methods by executing computer instructions in a memory, such as a general-purpose processor. The memory may be a non-transitory memory, such as a read-only memory (ROM), which may be integrated with the processor on the same chip or may be separately provided on different chips. The embodiment of the present application does not limit the type of memory and the configuration of the memory and the processor.

[0119] In a possible implementation, the at least one memory is located outside the device.

[0120] In yet another possible implementation, the at least one memory is located within the device.

[0121] In another possible implementation, part of the at least one memory is located inside the device, and another part of the memory is located outside the device.

[0122] In this application, the processor and the memory may also be integrated into one device, that is, the processor and the memory may also be integrated together. BRIEF DESCRIPTION OF THE DRAWINGS

[0123] FIG1 is a system architecture diagram of an OTA upgrade provided by this application;

[0124] FIG2 is a system architecture diagram of another OTA upgrade provided by this application;

[0125] FIG3 is a functional block diagram of the vehicle 10 provided by the present application;

[0126] FIG4 is a schematic diagram of a scenario in which a function failure of a core component provided by the present application occurs;

[0127] FIG5 is a schematic diagram of a flow chart of an upgrade method provided in an embodiment of the present application;

[0128] FIG6 is a schematic structural diagram of an upgrading device provided in an embodiment of the present application;

[0129] FIG7 is a schematic structural diagram of an upgrading device provided in an embodiment of the present application;

[0130] FIG8 is a schematic diagram of the structure of a chip provided in an embodiment of the present application. DETAILED DESCRIPTION

[0131] The embodiments of the present application are described below in conjunction with the drawings in the embodiments of the present application. It should be noted that, in this application, words such as "exemplary" or "for example" are used to indicate examples, illustrations or explanations. Any embodiment or design described in this application as "exemplary" or "for example" should not be interpreted as being more preferred or more advantageous than other embodiments or designs. Specifically, the use of words such as "exemplary" or "for example" is intended to present related concepts in a concrete way.

[0132] The “at least one” mentioned in the embodiments of this application refers to one or more, and “plurality” refers to two or more. “At least one of the following” or similar expressions refers to any combination of these items, including any combination of single items or plural items. For example, at least one of a, b, or c can represent: a, b, c, (a and b), (a and c), (b and c), or (a and b and c), where a, b, c can be single or multiple. “And / or” describes 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, where A and B can be singular or plural. The character “ / ” generally indicates that the related objects before and after are in an “or” relationship.

[0133] Furthermore, unless otherwise indicated, ordinal numbers such as "first" and "second" in the embodiments of this application are used to distinguish between multiple objects and are not used to define the order, timing, priority, or importance of multiple objects. For example, the first message and the second message are only used to distinguish different message types and do not indicate differences in structure, importance, etc. between the two messages.

[0134] First, some terms in this application are explained to facilitate understanding by those skilled in the art.

[0135] 1. OTA technology is a technology for downloading data via wireless networks. It is now widely used to upgrade vehicles, smart homes (TVs, gateways, refrigerators, etc.), mobile terminals (mobile phones, tablets, etc.), set-top boxes and other devices. OTA technology mainly performs automatic upgrades by downloading OTA upgrade packages (it also supports upgrading by copying OTA upgrade packages to SD cards). OTA upgrades are fast and have little impact on data, so OTA upgrades have become the main method for terminal function upgrades. For example, for vehicles, vehicle manufacturers (original equipment manufacturers, OEMs, or original equipment manufacturers) use OTA technology to upgrade related vehicle hardware or software, which helps manufacturers reduce recall costs, respond quickly to needs, and improve user experience.

[0136] Among them, the OTA server is the server responsible for managing the OTA upgrade process (or called the OEM server, also called the OEM cloud or OTA cloud). The terminal (for example, it can be a vehicle, TV, mobile phone, tablet computer, set-top box and other devices) is equipped with an OTA module (or called OTA upgrade control component). The OTA module can transmit information with the OTA server to complete the upgrade of components on the terminal (including both software and hardware, or the entire vehicle).

[0137] 2. The telematics box, also known as a car box (Tbox or T-box), is a portmanteau of the long-distance communication term "telecommunications" and the information science term "informatics." It can be literally defined as an information service system that uses computer systems, wireless communication technologies, satellite navigation devices, and Internet technologies built into vehicles such as automobiles, airplanes, ships, and trains to exchange text, voice, and other information. Simply put, it connects vehicles to the internet via wireless networks, providing drivers with essential information for driving and daily life.

[0138] 3. The electronic control unit (ECU) is a microcomputer controller specifically designed for automobiles. Like a regular computer, it consists of a microprocessor (e.g., a central processing unit (CPU)), memory (read-only memory (ROM), random access memory (RAM)), input / output (I / O) interfaces, an analog-to-digital converter (A / D), and large-scale integrated circuits such as those for shaping and driving. The onboard control unit in the embodiments of this application is the ECU.

[0139] 4. The vehicle control unit (VCU), also known as the vehicle controller for electric vehicles, is the assembly controller for the electric vehicle's powertrain. It coordinates the operation of various components, including the engine, drive motor, transmission, and power battery, improving the vehicle's power, safety, and economy. It is the core component of the electric vehicle's control system, controlling the starting, running, forward and backward movement, speed, and stopping of the electric vehicle's motor, as well as the vehicle's other electronic components. As the most central component of a pure electric vehicle's control system, the VCU is responsible for data exchange, safety management, driver intent interpretation, and energy flow management. The VCU collects signals from the motor control system, accelerator pedal, brake pedal, and other components. After comprehensively analyzing and responding to the driver's driving intent, the VCU monitors the operation of the underlying component controllers, playing a key role in ensuring the vehicle's proper operation, battery energy recovery through braking, network management, fault diagnosis and resolution, and vehicle status monitoring.

[0140] 5. Human machine interface (HMI), also known as human-machine interface, user interface or user interface, is the medium for interaction and information exchange between the system and the user. It realizes the conversion between the internal form of information and the form acceptable to humans.

[0141] 6. The Controller Area Network (CAN) bus is one of the most widely used fieldbuses internationally. Its high reliability and excellent error detection capabilities are highly valued, making it widely used in automotive computer control systems and industrial environments with harsh temperatures, strong electromagnetic radiation, and high vibration. The CAN bus is a widely used fieldbus with great potential in industrial measurement and control, industrial automation, and other fields. CAN is a bus-based serial communication network. The CAN bus offers the advantages of reliable, real-time, and flexible data communication. To ensure transparent design and flexible implementation, the CAN bus structure is divided into two layers: the physical layer and the data link layer (including the logical link control sublayer LLC and the medium access control sublayer (MAC)).

[0142] In order to better understand the upgrade method provided by the embodiment of the present application, the system architecture and business scenarios of the embodiment of the present application are described below. It should be noted that the system architecture and business scenarios described in this application are for the purpose of more clearly illustrating the technical solution of this application, and do not constitute a limitation on the technical solution provided by this application. It is known to those skilled in the art that with the evolution of the system architecture and the emergence of new business scenarios, the technical solutions provided by this application are also applicable to similar technical problems.

[0143] Please refer to Figure 1, which is a system architecture diagram of an OTA upgrade provided by this application, which may include a terminal 101 and an OTA server 102, wherein:

[0144] The OTA server 102 is the server that exchanges information with the terminal 101 during the OTA upgrade process. The OTA server 102 may include an OTA cloud-side upgrade management module 1020 and an OTA cloud-side upgrade package management module 1021. Generally speaking, the OTA server can instruct the terminal to upgrade a specific control unit. Optionally, the OTA server can also send ECU upgrade data to the terminal via the OTA cloud-side upgrade package management module 1021. In some specific implementation scenarios, the OTA server is also referred to as an OTA cloud, cloud-side server, or server.

[0145] Optionally, the OTA cloud-side upgrade package management module 1021 and the OTA cloud-side upgrade management module 1020 can be two independent hardware. In other words, the OTA cloud-side upgrade package management module 1021 can be a separate server that provides the terminal 101 with a service for downloading the installation package.

[0146] The terminal 101 is a terminal equipped with a control unit, such as a vehicle. The terminal 101 can obtain upgrade data from the OTA server 102 to upgrade the control unit.

[0147] The control unit in the embodiment of the present application may include all units in the terminal that are suitable for OTA upgrade, such as ECU, etc. The following embodiments are all described using ECU as an example.

[0148] Optionally, the terminal 101 may include an OTA end-side upgrade management module 1010 and an OTA end-side ECU upgrade package management module 1011. Optionally, the terminal 101 may also include an OTA end-side ECU upgrade management unit 1012 (not shown in Figure 1). Among them, the OTA end-side upgrade management module 1010 can interact with the OTA cloud-side upgrade management module 1020, and based on the software information of each ECU in the terminal 101 collected by the OTA end-side ECU upgrade management unit 1012, obtain the upgrade information from the OTA cloud-side upgrade management module 1020, and then trigger the OTA end-side ECU upgrade package management module 1011 to download the installation package. The OTA end-side ECU upgrade package management module 1011 can interact with the OTA cloud-side upgrade package management module 1021 to download and manage the installation package. The OTA end-side ECU upgrade management unit 1012 is responsible for the specific ECU upgrade (rollback) processing.

[0149] In some specific implementation scenarios, as shown in FIG2 , a system architecture diagram of another OTA upgrade provided by the present application, taking the terminal 101 as a vehicle as an example, the vehicle can be a vehicle based on the vehicle electrical / electronic architecture (E / E) architecture, and the vehicle can include at least one of the following components: a mobile data center (MDC), a human-machine interaction (HMI), a terminal upgrade management unit gateway (GW), a telematics box (T-box, or TCU), an electronic control unit (ECU), etc. Among them, GW is the core component in the vehicle's electrical and electronic architecture. As the data interaction hub of the vehicle network, it can route network data such as the control area network (CAN), the local interconnect network (LIN), the multimedia data transmission (MOST), and FlexRay in different networks. MDC is the vehicle's intelligent on-board computing platform. T-box is mainly used to communicate with the vehicle's exterior, background systems, and mobile phone applications (APPs). HMI is the vehicle's information input, entertainment, and interaction system. ECU can be a vehicle-specific microcomputer controller.

[0150] For example, an update master module (which can be regarded as an OTA master) is deployed in the GW of the terminal 101, and an update slave module (which can be regarded as an OTA slave) is deployed in multiple components of the terminal 101. The update master module in the GW can communicate with the upgrade slave modules in other components, and can also communicate with the OTA server 102. The OTA master module can also be deployed in other components of the vehicle, or it can be an independent module independent of other components, which is not limited in this embodiment of the present application.

[0151] For example, the OTA client-side upgrade management module 1010, OTA client-side ECU upgrade package management module 1011, and OTA client-side ECU upgrade management unit 1012 in the terminal 101 may be units within the MDC. Specifically, the OTA client-side upgrade management module 1010 may establish a connection with the OTA cloud-side upgrade management module 1020 via a T-box; and specifically, the OTA client-side ECU upgrade package management module 1011 may also establish a connection with the OTA cloud-side upgrade package management module 1021 via a T-box.

[0152] The terminal 101 typically has only one OTA client-side upgrade management module 1010, which can be deployed in a T-box or gateway. The OTA client-side ECU upgrade package management module 1011 can be deployed separately in the terminal 101. Optionally, functionally related ECUs in the terminal 101 can be grouped together and managed by jointly deploying an OTA client-side ECU upgrade package management module 1011 and an OTA client-side ECU upgrade management unit 1012. The OTA client-side ECU upgrade package management module 1011 and the OTA client-side ECU upgrade management unit 1012 are interconnected via a gateway.

[0153] For ease of understanding, this application is mainly schematically illustrated with the terminal as the vehicle. In conjunction with the functional block diagram of the vehicle 10 provided in the embodiment of the present application shown in Figure 3. The vehicle 10 may include various subsystems, such as a travel system 110, a sensor system 120, a control system 130, one or more peripheral devices 140, a power supply 150, a computer system 160, and a user interface 170. Optionally, the vehicle 10 may include more or fewer subsystems, and each subsystem may include multiple elements (or vehicle-mounted components or components). In addition, each subsystem and element of the vehicle 10 can be interconnected by wire or wirelessly.

[0154] Optionally, the elements in each subsystem shown in Figure 3 are only an example. In actual applications, the elements in the above subsystems may be added or deleted according to actual needs. Figure 3 should not be understood as a limitation on the embodiments of the present application.

[0155] It should be understood that the upgrade method involved in the scheme of the present application can be applicable to any vehicle-mounted components / elements in the block diagram shown in Figure 3, and can also be applicable to components not included in the block diagram, or can also be applicable to some functional domain control components that manage the above components, such as the intelligent driving domain controller (multi domain controller, MDC) domain, the vehicle domain controller (vehicle domain controller, VDC) domain, the cockpit domain controller (cockpit domain controller, CDC) domain, etc. This application does not impose any restrictions on this.

[0156] The vehicle 10 may be a car, truck, motorcycle, bus, boat, airplane, helicopter, lawn mower, recreational vehicle, amusement park vehicle, construction equipment, tram, golf cart, train, and cart, etc., and the embodiments of the present application do not impose any particular limitation.

[0157] In existing OTA upgrade solutions, if the core components of the vehicle fail to be upgraded, the core components will become "bricked". For example, please refer to Figure 4, which is a schematic diagram of the scenario in which the function of the core components provided by this application fails. As shown in Figure 4:

[0158] Scenario 1: During a core component upgrade (e.g., flashing the battery management system (BMS), microcontroller unit (MCU), or power distribution unit (PDU)), the vehicle battery fails. In this scenario, the battery failure prevents the OTA upgrade from proceeding. Even if the T-box restarts the OTA upgrade after the battery failure is recovered, the upper-layer applications of the BMS, MCU, or PDU are damaged, making it impossible to control vehicle-related signals and preventing the OTA upgrade from proceeding.

[0159] Scenario 2: During a core component upgrade (for example, flashing the passive entry passive start (PEPS) system), the T-box reboots. In this scenario, the core component flashing process is interrupted due to the T-box reboot. After the T-box recovers / restarts, it needs to restore the vehicle upgrade-related state (for example, restore the high-voltage signal). However, due to damage to the upper-layer application of PEPS, PEPS cannot restore the high-voltage signal, and therefore the OTA upgrade task cannot be resumed.

[0160] Scenario 3 (not shown in FIG4 ): Software failure of a core component (ie, not a hardware problem). In this scenario 3, due to a software failure of a core component, the OTA upgrade task cannot be issued, and thus the OTA upgrade task cannot be performed.

[0161] The above scenarios all involve core component failures during daily use or OTA upgrades. These scenarios can cause critical issues such as vehicle power failure and vehicle wake-up failure, preventing the owner from using the vehicle and preventing OTA upgrades from proceeding normally. In such cases, operators are required to intervene, such as using a tow truck or near-end flashing to restore the vehicle. This method is inefficient and produces a poor user experience.

[0162] Based on this, this application proposes an upgrade method that can improve the efficiency of vehicle rescue and help enhance user experience.

[0163] The following is a detailed introduction to the upgrade method and related devices provided by this application:

[0164] Please refer to Figure 5, which is a flow chart of the upgrade method provided by an embodiment of the present application. As shown in Figure 5, the upgrade method includes the following steps S501 to S502. The execution subject of the method shown in Figure 5 can be a vehicle, or the execution subject of the method shown in Figure 5 can also be a chip or vehicle-mounted component in which the upgrade master software is deployed in the vehicle. For example, the upgrade master software can be deployed in a vehicle-mounted component (or chip) such as the T-box, CDC, VDC, MDC, or gateway (GW) of the vehicle, and this application does not limit this. For the convenience of description, Figure 5 mainly uses the vehicle-mounted component in which the upgrade master software is deployed in the vehicle as an example of the execution subject of the method. To simplify the description, it is referred to as the vehicle-mounted upgrade component hereinafter. It should be noted that Figure 5 is a schematic flow chart of an embodiment of the method of the present application, showing the detailed communication steps or operations of the method, but these steps or operations are only examples. The embodiment of the present application can also perform other operations or variations of the various operations in Figure 5. In addition, the steps in FIG5 may be performed in a different order than that shown in FIG5 , and not all operations in FIG5 may be performed.

[0165] S501: When a first component fails, the vehicle-mounted upgrade component upgrades the first component according to first policy information.

[0166] The first policy information is used to indicate ignoring the results of N upgrade condition checks, or the first policy information is used to indicate ignoring the execution of N upgrade condition checks, or the first policy information is used to indicate ignoring the results of N1 upgrade condition checks and indicating ignoring the execution of N2 upgrade condition checks, where N1+N2=N, N1 and N2 are non-negative integers, and N is an integer greater than 0.

[0167] It should be noted that "ignoring the results of N / N1 upgrade condition checks" can be understood as executing N / N1 upgrade condition checks but ignoring the results of the checks (that is, even if the checks are executed, the results of the checks are ignored, or it can be described as not caring whether the results of the checks pass). In this way, in some scenarios, the existing upgrade check process can be reused as much as possible, which has a relatively small impact on the existing upgrade check process and thus requires relatively small changes, which can save development costs; "ignoring the execution of N / N2 upgrade condition checks" can be understood as not executing N / N2 upgrade condition checks, or skipping the execution of N / N2 upgrade condition checks. This can improve upgrade efficiency in some scenarios. In other words, in the case of a failure of the first component, the installation / flashing of the first component can be performed directly.

[0168] Exemplarily, the N upgrade condition checks involved in this application include one or more of the following: pulling a high-voltage signal check (or called an upgraded high-voltage signal), pulling a vehicle ignition signal (such as a KL15 signal) check, checking the vehicle's power battery percentage, checking the vehicle's speed, checking the vehicle's gear position, checking the vehicle's ignition status, checking the vehicle's on-board diagnostic interface status, checking whether the vehicle allows whole-vehicle upgrades or whole-vehicle flashing, checking the vehicle's handbrake status, checking the vehicle's fast charging gun connection status, checking the vehicle's charging gun connection status, checking the vehicle's fuel filler cap status, checking the vehicle's battery percentage, or notifying the vehicle to enter upgrade mode, etc.

[0169] Optionally, in some feasible implementations, in addition to indicating to ignore the results of N upgrade condition checks or to ignore the execution of N upgrade condition checks, the first policy information may also indicate to execute K upgrade condition checks. Therefore, in the event of a failure of the first component, the first component may be installed / flashed if K upgrade condition checks are executed and the K upgrade condition checks pass, where K is an integer greater than or equal to 0. It should be understood that when K is equal to 0, it is equivalent to the first policy information only indicating to ignore the results of N upgrade condition checks or to ignore the execution of N upgrade condition checks (or the first policy information only indicating to ignore the results of N1 upgrade condition checks and to ignore the execution of N2 upgrade condition checks). Therefore, in the event of a failure of the first component, the installation / flashing of the first component may be directly executed. When K is an integer greater than 0, for example, N upgrade condition checks may include checking the high-voltage signal, checking the vehicle ignition signal (such as the KL15 signal), checking the vehicle's power battery percentage, checking the vehicle's ignition status, checking the vehicle's on-board diagnostic interface status, checking whether the vehicle allows whole-vehicle upgrades or whole-vehicle flashing, checking the vehicle's handbrake status, checking the vehicle's fast charging gun connection status, checking the vehicle's charging gun connection status, checking the vehicle's fuel filler cap status, checking the vehicle's battery percentage, and notifying the vehicle to enter upgrade mode, etc.; K upgrade condition checks may include checking the vehicle's speed, checking the vehicle's gear position, etc.

[0170] It should be understood that the first policy information is the upgrade policy information corresponding to the failure of the first component (or the upgrade policy information corresponding to the emergency rescue task, or the upgrade policy information under the emergency rescue mode). Or it can be understood that the first policy information indicates the emergency rescue task. Here, the first policy information indicating the emergency rescue task can be understood as the specific binding / correspondence / association relationship between the emergency rescue task and the aforementioned specific upgrade policy information. Therefore, if the first policy information directly indicates a task with a special mark (i.e., an emergency rescue task), then based on the association between the emergency rescue task and the upgrade policy information, the corresponding upgrade policy information can be determined. In an embodiment of the present application, the first component can be a power-related component of the vehicle (or called a core component / key component of the vehicle). Generally speaking, when a power-related component of the vehicle fails, it will affect the normal use of the entire vehicle, so emergency rescue is required. Accordingly, the corresponding upgrade strategy is the first policy information. Exemplarily, the power-related components of the vehicle may include BMS, MCU, PDU, PEPS, etc., and this application does not impose any restrictions on this.

[0171] It is understandable that the first policy information involved in the embodiments of the present application can be determined / generated by the vehicle (or the on-board upgrade component in the vehicle), or the first policy information can also be pre-configured in the vehicle. That is to say, in the case of determining that the first component has failed, the on-board upgrade component in the vehicle can automatically generate the first policy information, or, in the case of determining that the first component has failed, the on-board upgrade component in the vehicle can also read the first policy information pre-configured in the vehicle, and then the on-board upgrade component in the vehicle can upgrade the first component according to the first policy information. Optionally, in some possible implementations, the first policy information can also come from the server, that is, in the case of determining that the first component has failed, the vehicle can report the fault information to the server, and then the server can send the first policy information to the vehicle based on the received fault information, and then the on-board upgrade component in the vehicle can upgrade the first component based on the received first policy information. It should be noted that this application is mainly understood as the first policy information being determined by the on-board upgrade component in the vehicle or pre-configured in the vehicle.

[0172] In specific implementation, the on-board upgrade component in the vehicle can obtain the abnormal status information of the vehicle (or other components in the vehicle), and determine the corresponding abnormal level based on the abnormal status information obtained, and then select the strategy information to perform the upgrade task based on the relationship between the abnormal level and the preset conditions. Here, taking the abnormal status information of the first component as an example, when the abnormal status information of the first component is obtained and, based on the abnormal status information of the first component, it is determined that the corresponding first abnormal level meets the preset conditions, the first component is upgraded according to the first strategy information. It should be understood that the first abnormal level belongs to one of multiple abnormal levels, and multiple abnormal levels are used to describe the severity of the fault.

[0173] In one possible implementation, multiple anomaly levels may be positively correlated with the severity of the fault. Therefore, the on-board upgrade component may upgrade the first component according to the first policy information if the first anomaly level is not lower than a level threshold. In another possible implementation, multiple anomaly levels may be negatively correlated with the severity of the fault. Therefore, the on-board upgrade component may upgrade the first component according to the first policy information if the first anomaly level is not higher than the level threshold. Here, "not lower than" may be understood as higher than or equal to, and "not higher than" may be understood as lower than or equal to.

[0174] For ease of understanding, the embodiments of the present application are mainly understood by taking the positive correlation between multiple abnormality levels and the severity of the fault as an example, that is, the higher the abnormality level, the more serious the fault. For example, as shown in Table 1 below, Table 1 shows a way of dividing the abnormality levels. Among them, when the abnormal status information of the vehicle is "1. The precondition check fails and the formal flashing process is not started", or "2. The upgrade is successful, and the exit from OTA fails", the corresponding abnormality level is level 1; when the abnormal status information of the vehicle is "The upgrade fails, and the whole vehicle rolls back successfully", the corresponding abnormality level is level 2; when the abnormal status information of the vehicle is "The upgrade fails, the rollback also fails, but the components can be started normally", the corresponding abnormality level is level 3; when the abnormal status information of the vehicle is "1. Non-power-related components are flashed and cannot be started (that is, the OTA upgrade process When the vehicle's abnormal status information is "1. Non-power-related components are dead / bricked)", or "2. Software function failure of non-power-related components and cannot be used", the corresponding abnormality level is level 4; when the vehicle's abnormal status information is "1. Power-related components are dead and cannot be started (that is, power-related components are dead / bricked during OTA upgrade)", or "2. Software function alarm of power-related components affects driving use", the corresponding abnormality level is level 5; when the vehicle's abnormal status information is "Upgrade stuck and does not exit, resulting in power supply and upgrade incomplete", the corresponding abnormality level is level 6. Taking the level threshold of level 5 as an example, when an error of level 5 or above occurs, the on-board upgrade component can upgrade the first component according to the first strategy information.

[0175] Table 1

[0176] Optionally, before upgrading the first component according to the first policy information, the vehicle-mounted upgrade component may also first determine whether there is a user in the current vehicle. If the user is in the vehicle, the vehicle-mounted upgrade component may immediately upgrade the first component according to the first policy information (i.e., immediately perform the rescue mission), so that the vehicle rescue can be completed as soon as possible so that the user can use the vehicle and improve the user experience; if the user is not in the vehicle, the vehicle-mounted upgrade component upgrades the first component according to the first policy information at the first moment. Here, the first moment is the rescue time scheduled by the vehicle-mounted upgrade component with the vehicle. That is, the vehicle-mounted upgrade component will send the rescue time to the vehicle. After the scheduled rescue time arrives, the vehicle automatically wakes up, so that the vehicle-mounted upgrade component can upgrade the first component according to the first policy information. It should be understood that when the user is not in the vehicle and before the first moment arrives, the first vehicle control signal will be released, which is beneficial to vehicle energy saving. Here, the first vehicle control signal is the signal associated with the execution of M upgrade condition checks (or described as the first vehicle control signal being a signal that needs to be pulled when performing a normal OTA upgrade / non-emergency rescue mission). In addition, when the user is not in the vehicle and before the first moment arrives, a second vehicle control signal can be activated. This facilitates upgrading the first component directly according to the first strategy information after the first moment arrives, which helps improve rescue efficiency. Here, the second vehicle control signal is a signal associated with the first strategy information (or described as a signal that needs to be activated when performing an emergency rescue mission, or a signal that needs to be activated in emergency rescue mode).

[0177] Generally speaking, the second vehicle control signal is included in the first vehicle control signal. Exemplarily, the first vehicle control signal can be one or more of the following signals: a vehicle-wide sleep-prohibited signal, a remote mode signal, a vehicle ignition signal (such as a KL15 signal), an upgraded high-voltage signal, a mutually exclusive signal, a gear position flashing signal, a CAN network maintenance signal, etc. Exemplarily, the second vehicle control signal can be one or more of the following signals: a vehicle-wide sleep-prohibited signal, a remote mode signal, a KL15 signal (in emergency rescue mode, the result of the device being pulled up is ignored even if it is pulled up (i.e., it does not matter whether it is pulled up successfully)), an upgraded high-voltage signal (in emergency rescue mode, the result of the device being pulled up is ignored even if it is pulled up (i.e., it does not matter whether it is pulled up successfully)), a mutually exclusive signal, a gear position flashing signal, a CAN network maintenance signal, etc.

[0178] Optionally, before upgrading the first component according to the first policy information, the vehicle's onboard upgrade component may further obtain a first user instruction input by the user. The first user instruction is used to trigger the onboard upgrade component to upgrade the first component according to the first policy information. Here, the first user instruction input by the user may be an operation instruction entered / selected by the user on the user interface / visual interface.

[0179] It should be understood that when the vehicle-mounted upgrade component upgrades the first component according to the first strategy information, it can ignore the results of N upgrade condition checks, or directly install / flash the first component without performing N upgrade condition checks. In other words, this application simplifies the pre-condition judgment and related processing procedures to complete the flashing of core components.

[0180] Optionally, after the first component is successfully upgraded, the vehicle status can be reset, that is, the vehicle can be restored to a normal and usable state, and support normal OTA upgrades and subsequent use of the vehicle by the owner.

[0181] S502: If the first component is not faulty, the vehicle-mounted upgrade component performs M upgrade condition checks according to the second policy information, and upgrades the first component if the M upgrade condition checks pass.

[0182] It should be understood that the second policy information is the upgrade policy information corresponding to the normal OTA upgrade (or the upgrade policy information corresponding to the non-emergency rescue task, or the upgrade policy information in normal mode). Or it can be understood that the second policy information indicates a non-emergency rescue task or a normal OTA upgrade task, or the second policy information indicates the execution of M upgrade condition checks. The first policy information is associated with the second policy information. Here, the association of the first policy information with the second policy information can be understood as the first policy information being included in the second policy information (or the first policy information being a subset of the second policy information). Alternatively, the association of the first policy information with the second policy information can also be understood as the upgrade condition check indicated by the first policy information being generated / determined based on the upgrade condition check indicated by the second policy information. Generally speaking, the second policy information comes from the server, that is, in the normal OTA upgrade process, the second policy information is generated by the server and sent to the vehicle. Among them, the second policy information can be associated with M upgrade condition checks, where the M upgrade condition checks are upgrade condition checks corresponding to when the first component is not faulty, and M is an integer greater than 0. It should be understood that in this embodiment of the present application, if the first component is not faulty, the vehicle-mounted upgrade component needs to perform M upgrade condition checks. Only when the results of all M upgrade condition checks are successful / passed can the first component be installed / flashed. Taking any one of the M upgrade condition checks, such as the first upgrade condition check, as an example, "the first upgrade condition check has passed" can be understood as: the result of the first upgrade condition check is successful / passed.

[0183] In specific implementations, the vehicle's onboard upgrade component can obtain abnormal status information of the vehicle (or each component in the vehicle) and determine the corresponding abnormality level based on the acquired abnormal status information. When the abnormality level does not meet the preset conditions, the first component is upgraded according to the second policy information. Taking Table 1 as an example, assuming the level threshold is level 5, when an error below level 5 (i.e., level 4 or below) occurs, the onboard upgrade component can upgrade the first component according to the second policy information.

[0184] It should be understood that the N upgrade condition checks referred to in this application may be included in the M upgrade condition checks, or the N upgrade condition checks may be different from the M upgrade condition checks, or some of the N upgrade condition checks may be included in the M upgrade condition checks, while other upgrade condition checks may be different from the M upgrade condition checks. The M / N upgrade conditions may not be issued by the server but may be pre-configured in the vehicle.

[0185] Exemplarily, the M upgrade condition checks involved in this application include one or more of the following: pulling a high-voltage signal check, pulling a vehicle ignition signal (such as a KL15 signal check), checking the vehicle's power battery percentage, checking the vehicle's speed, checking the vehicle's gear position, checking the vehicle's ignition status, checking the vehicle's on-board diagnostic interface status, checking whether the vehicle allows whole-vehicle upgrades or whole-vehicle flashing, checking the vehicle's handbrake status, checking the vehicle's fast charging gun connection status, checking the vehicle's charging gun connection status, checking the vehicle's fuel filler cap status, checking the vehicle's battery percentage, or notifying the vehicle to enter upgrade mode, etc.

[0186] Generally speaking, 0<N≤M. For example, the M upgrade condition checks are respectively pulling the high-voltage signal check, pulling the vehicle ignition signal (such as the KL15 signal) check, checking the vehicle's power battery percentage, checking the vehicle's speed, and checking the vehicle's gear position (i.e., M=5); the N upgrade condition checks are respectively pulling the high-voltage signal check, pulling the vehicle ignition signal (such as the KL15 signal) check, and checking the vehicle's power battery percentage (i.e., N=3). For another example, the M upgrade condition checks are respectively pulling the high-voltage signal check, pulling the vehicle ignition signal (such as the KL15 signal) check, checking the vehicle's power battery percentage, checking the vehicle's speed, and checking the vehicle's gear position (i.e., M=5); the N upgrade condition checks are respectively pulling the high-voltage signal check, pulling the vehicle ignition signal (such as the KL15 signal) check, checking the vehicle's power battery percentage, checking the vehicle's handbrake status, and checking the vehicle's fast charging gun connection status (i.e., N=5).

[0187] Optionally, in some feasible implementations, when the first policy information, in addition to instructing to ignore the results of N upgrade condition checks or to ignore the execution of N upgrade condition checks, can also instruct to execute K upgrade condition checks, the K upgrade conditions can be included in the M upgrade conditions. In this case, N, K and M can satisfy: N+K=M. For example, N (where N=12) upgrade condition checks can include pulling a high-voltage signal check, pulling a vehicle ignition signal (such as a KL15 signal) check, checking the vehicle's power battery percentage, checking the vehicle's ignition status, checking the vehicle's on-board diagnostic interface status, checking whether the vehicle allows full vehicle upgrades or full vehicle flashing, checking the vehicle's handbrake status, checking the vehicle's fast charging gun connection status, checking the vehicle's charging gun connection status, checking the vehicle's fuel filler cap status, checking the vehicle's battery percentage, and notifying the vehicle to enter upgrade mode; K (where K=2) upgrade condition checks can include checking the vehicle The vehicle speed is checked, and the gear position of the vehicle is checked; M (where M=14) upgrade condition checks may include pulling a high-voltage signal to check, pulling a vehicle ignition signal (such as a KL15 signal) to check, checking the vehicle's power battery percentage, checking the vehicle's speed, checking the vehicle's gear position, checking the vehicle's ignition status, checking the vehicle's on-board diagnostic interface status, checking whether the vehicle allows whole-vehicle upgrades or whole-vehicle flashing, checking the vehicle's handbrake status, checking the vehicle's fast charging gun connection status, checking the vehicle's charging gun connection status, checking the vehicle's fuel filler cap status, checking the vehicle's battery percentage, and notifying the vehicle to enter upgrade mode.

[0188] In an embodiment of the present application, when an abnormality occurs in a core component of the vehicle, the vehicle side actively identifies the abnormal status information and generates a first strategy information to rescue the core component. This automatic rescue method that does not require human participation can reduce operating costs, and at the same time is conducive to improving rescue efficiency and enhancing user experience.

[0189] The above describes in detail the methods of the embodiments of the present application. The following provides an apparatus for implementing any method in the embodiments of the present application. For example, an apparatus is provided that includes units (or means) for implementing each step performed by the device in any of the above methods.

[0190] Please refer to Figure 6, which is a structural diagram of an upgrading device provided in an embodiment of the present application.

[0191] As shown in Figure 6, the upgrading device 60 may include a transceiver unit 601 and a processing unit 602. The transceiver unit 601 and the processing unit 602 may be software, hardware, or a combination of software and hardware.

[0192] The transceiver unit 601 can implement a sending function and / or a receiving function, and can also be described as a transceiver unit. The transceiver unit 601 can also be a unit that integrates an acquisition unit (or receiving unit) and a sending unit, wherein the acquisition unit is used to implement the receiving function and the sending unit is used to implement the sending function. Optionally, the transceiver unit 601 can be used to receive information sent by other devices, and can also be used to send information to other devices.

[0193] In one possible design, the upgrade device 60 may correspond to the vehicle-mounted device or chip in which the upgrade master control software is deployed in the method embodiment shown in FIG5 . The upgrade device 60 may include a unit for executing the operations performed by the upgrade master control software in the method embodiment shown in FIG5 , and each unit in the upgrade device 60 is respectively configured to implement the operations performed by the upgrade master control software in the method embodiment shown in FIG5 . The description of each unit is as follows:

[0194] Processing unit 602 is configured to upgrade the first component according to first policy information when the first component fails, where the first policy information is used to indicate ignoring results of N upgrade condition checks, or the first policy information is used to indicate ignoring execution of the N upgrade condition checks, where N is an integer greater than 0;

[0195] The processing unit 602 is used to perform M upgrade condition checks according to the second policy information when the first component is not faulty, where M is an integer greater than 0; the processing unit 602 is used to upgrade the first component when the M upgrade condition checks are passed, wherein passing the first upgrade condition check includes the result of the first upgrade condition check being successful, and the first upgrade condition check is any one of the M upgrade condition checks.

[0196] Optionally, the transceiver unit 601 is configured to receive second policy information from the server when the first component is not faulty.

[0197] In a possible implementation manner, the first policy information is associated with the second policy information, the second policy information comes from a server, and the first policy information is determined by the vehicle or pre-configured in the vehicle.

[0198] In a possible implementation, the processing unit 602 is further configured to:

[0199] Acquiring abnormal status information of the first component;

[0200] determining a first abnormality level according to the abnormal state information, where the first abnormality level belongs to one of a plurality of abnormality levels, where the plurality of abnormality levels are used to describe the severity of the fault;

[0201] When the first component fails, when the first component is upgraded according to the first policy information, the processing unit 602 is configured to:

[0202] When the first abnormality level meets a preset condition, the first component is upgraded according to the first policy information.

[0203] In a possible implementation, the multiple abnormality levels are positively correlated with the severity of the fault;

[0204] The first abnormality level meets the preset conditions, including:

[0205] The first abnormality level is not lower than a level threshold.

[0206] In one possible implementation, the multiple abnormality levels are negatively correlated with the fault severity;

[0207] The first abnormality level meets the preset conditions, including:

[0208] The first abnormality level is not higher than a level threshold.

[0209] In a possible implementation manner, the first component is a power-related component of the vehicle.

[0210] In one possible implementation, the power-related components include one or more of the following:

[0211] Battery management system BMS, microcontroller MCU, or power distribution unit PDU.

[0212] In one possible implementation, the N upgrade condition checks include one or more of the following:

[0213] Pull the high-voltage signal to check, pull the vehicle ignition signal to check, check the vehicle's power battery percentage, check the vehicle's speed, check the vehicle's gear position, check the vehicle's ignition status, check the vehicle's on-board diagnostic interface status, check whether the vehicle allows whole-vehicle upgrade or whole-vehicle flashing, check the vehicle's handbrake status, check the vehicle's fast charging gun connection status, check the vehicle's charging gun connection status, check the vehicle's fuel filler cap status, check the vehicle's battery percentage, or notify the vehicle to enter upgrade mode.

[0214] In a possible implementation, the upgrading the first component according to the first policy information includes:

[0215] The first component is upgraded at a first moment according to the first policy information.

[0216] In a possible implementation, the upgrading the first component according to the first policy information at the first moment includes:

[0217] When the user is not in the car, the first component is upgraded according to the first policy information at the first moment.

[0218] In a possible implementation, before upgrading the first component according to the first policy information at the first moment, the processing unit 602 is further configured to:

[0219] releasing a first vehicle control signal, where the first vehicle control signal is a signal associated with executing the M upgrade condition checks;

[0220] A second vehicle control signal is activated, where the second vehicle control signal is a signal associated with the first strategy information.

[0221] In a possible implementation manner, the second vehicle control signal is included in the first vehicle control signal.

[0222] In a possible implementation, when the first component is upgraded according to the first policy information, the processing unit 602 is configured to:

[0223] When the user is in the car, the first component is upgraded according to the first policy information.

[0224] In a possible implementation, before upgrading the first component according to the first policy information, the processing unit 602 is configured to:

[0225] Obtaining a first user instruction;

[0226] Based on the first user instruction, the first component is upgraded according to the first policy information.

[0227] Regarding the technical effects brought about by this design and any possible implementation method, please refer to the introduction of the technical effects corresponding to Figure 5 and the corresponding implementation method.

[0228] In another possible design of the upgrade device 60 shown in FIG6 , the upgrade device 60 may correspond to the server in the method embodiment shown in FIG5 . For example, the upgrade device 60 may be a server or a chip in the server. The upgrade device 60 may include a unit for executing the operations performed by the server in the method embodiment shown in FIG5 , and each unit in the upgrade device 60 is respectively for implementing the operations performed by the server in the method embodiment shown in FIG5 . The description of each unit is as follows:

[0229] The processing unit 602 is configured to generate second policy information;

[0230] The transceiver unit 601 is configured to send the second strategy information to the vehicle;

[0231] The vehicle includes a first component, the second policy information is associated with M upgrade condition checks, the M upgrade condition checks are upgrade condition checks corresponding to when the first component is not faulty, the second policy information is associated with the first policy information, the first policy information is upgrade policy information corresponding to when the first component is faulty, the first policy information is used to indicate ignoring the results of the N upgrade condition checks, or the first policy information is used to indicate ignoring the execution of the N upgrade condition checks, M is an integer greater than 0, and N is an integer greater than 0.

[0232] In a possible implementation manner, the first strategy information is determined by the vehicle or preconfigured in the vehicle.

[0233] In a possible implementation manner, the first component is a power-related component of the vehicle.

[0234] In one possible implementation, the power-related components include one or more of the following:

[0235] Battery management system BMS, microcontroller MCU, or power distribution unit PDU.

[0236] In one possible implementation, the N upgrade condition checks include one or more of the following:

[0237] Pull the high-voltage signal to check, pull the vehicle ignition signal to check, check the vehicle's power battery percentage, check the vehicle's speed, check the vehicle's gear position, check the vehicle's ignition status, check the vehicle's on-board diagnostic interface status, check whether the vehicle allows whole-vehicle upgrade or whole-vehicle flashing, check the vehicle's handbrake status, check the vehicle's fast charging gun connection status, check the vehicle's charging gun connection status, check the vehicle's fuel filler cap status, check the vehicle's battery percentage, or notify the vehicle to enter upgrade mode.

[0238] Regarding the technical effects brought about by this design and any possible implementation method, please refer to the introduction of the technical effects corresponding to Figure 5 and the corresponding implementation method.

[0239] Optionally, in any possible design of the upgrading device 60 shown in FIG6 :

[0240] In one implementation, the upgrade device is a communication device. When the upgrade device is a communication device, the transceiver unit may be a transceiver or an input / output interface; and the processing unit may be at least one processor. Alternatively, the transceiver may be a transceiver circuit. Alternatively, the input / output interface may be an input / output circuit.

[0241] In another implementation, the upgrade device is a chip (system) or circuit used in a communication device. When the upgrade device is a chip (system) or circuit used in a communication device, the transceiver unit can be a communication interface (input / output interface), interface circuit, output circuit, input circuit, pin, or related circuit on the chip (system) or circuit; the processing unit can be at least one processor, processing circuit, or logic circuit.

[0242] According to an embodiment of the present application, each unit in the device shown in Figure 6 can be separately or all merged into one or several other units to constitute, or one (some) unit therein can also be split into multiple smaller units in function to constitute, which can achieve the same operation without affecting the realization of the technical effects of the embodiments of the present application. The above-mentioned units are divided based on logical functions. In practical applications, the functions of a unit can also be implemented by multiple units, or the functions of multiple units can be implemented by one unit. In other embodiments of the present application, other units can also be included based on electronic equipment. In practical applications, these functions can also be implemented with the assistance of other units, and can be implemented by collaboration of multiple units.

[0243] It should be noted that the implementation of each unit may also refer to the corresponding description of the method embodiment shown in FIG5 .

[0244] In the upgrade device 60 described in Figure 6, when an abnormality occurs in a core component of the vehicle, the upgrade device 60 actively identifies the abnormal status information and generates a first strategy information to rescue the core component. This automatic rescue method that does not require human participation can reduce operating costs, and at the same time is conducive to improving rescue efficiency and enhancing user experience.

[0245] Please refer to Figure 7, which is a structural diagram of an upgrading device provided in an embodiment of the present application.

[0246] It should be understood that the upgrading device 70 shown in FIG7 is only an example, and the upgrading device of the embodiment of the present application may also include other components, or include components with similar functions to the components in FIG7, or not include all the components in FIG7.

[0247] The upgrading device 70 includes a communication interface 701 and at least one processor 702 .

[0248] The upgrade device 70 can correspond to any device in the vehicle-mounted device or server deployed with the upgrade master control software. The communication interface 701 is used to send and receive signals, and at least one processor 702 executes program instructions, so that the upgrade device 70 implements the corresponding process of the method executed by the corresponding device in the above method embodiment.

[0249] In one possible design, the upgrade device 70 may correspond to the vehicle-mounted device or chip that deploys the upgrade master control software in the method embodiment shown in FIG7 . The upgrade device 70 may include components for executing the operations performed by the upgrade master control software in the method embodiment described above. Furthermore, each component in the upgrade device 70 is configured to implement the operations performed by the upgrade master control software in the method embodiment described above. Specifically, the upgrade device 70 may be as follows:

[0250] In the event of a failure of the first component, upgrading the first component according to first policy information, where the first policy information is used to indicate ignoring results of N upgrade condition checks, or the first policy information is used to indicate ignoring execution of the N upgrade condition checks, where N is an integer greater than 0;

[0251] In a case where the first component is not faulty, M upgrade condition checks are performed according to the second policy information, where M is an integer greater than 0; in a case where the M upgrade condition checks are passed, the first component is upgraded, wherein passing the first upgrade condition check includes the result of the first upgrade condition check being successful, and the first upgrade condition check is any one of the M upgrade condition checks.

[0252] In a possible implementation manner, the first policy information is associated with the second policy information, the second policy information comes from a server, and the first policy information is determined by the vehicle or pre-configured in the vehicle.

[0253] In one possible implementation, the method further includes:

[0254] Acquiring abnormal status information of the first component;

[0255] determining a first abnormality level according to the abnormal state information, where the first abnormality level belongs to one of a plurality of abnormality levels, where the plurality of abnormality levels are used to describe the severity of the fault;

[0256] When the first component fails, upgrading the first component according to the first policy information includes:

[0257] When the first abnormality level meets a preset condition, the first component is upgraded according to the first policy information.

[0258] In a possible implementation, the multiple abnormality levels are positively correlated with the severity of the fault;

[0259] The first abnormality level meets the preset conditions, including:

[0260] The first abnormality level is not lower than a level threshold.

[0261] In one possible implementation, the multiple abnormality levels are negatively correlated with the fault severity;

[0262] The first abnormality level meets the preset conditions, including:

[0263] The first abnormality level is not higher than a level threshold.

[0264] In a possible implementation manner, the first component is a power-related component of the vehicle.

[0265] In one possible implementation, the power-related components include one or more of the following:

[0266] Battery management system BMS, microcontroller MCU, or power distribution unit PDU.

[0267] In one possible implementation, the N upgrade condition checks include one or more of the following:

[0268] Pull the high-voltage signal to check, pull the vehicle ignition signal to check, check the vehicle's power battery percentage, check the vehicle's speed, check the vehicle's gear position, check the vehicle's ignition status, check the vehicle's on-board diagnostic interface status, check whether the vehicle allows whole-vehicle upgrade or whole-vehicle flashing, check the vehicle's handbrake status, check the vehicle's fast charging gun connection status, check the vehicle's charging gun connection status, check the vehicle's fuel filler cap status, check the vehicle's battery percentage, or notify the vehicle to enter upgrade mode.

[0269] In a possible implementation, the upgrading the first component according to the first policy information includes:

[0270] The first component is upgraded at a first moment according to the first policy information.

[0271] In a possible implementation, the upgrading the first component according to the first policy information at the first moment includes:

[0272] When the user is not in the car, the first component is upgraded according to the first policy information at the first moment.

[0273] In a possible implementation, before upgrading the first component according to the first policy information at the first moment, the method further includes:

[0274] releasing a first vehicle control signal, where the first vehicle control signal is a signal associated with executing the M upgrade condition checks;

[0275] A second vehicle control signal is activated, where the second vehicle control signal is a signal associated with the first strategy information.

[0276] In a possible implementation manner, the second vehicle control signal is included in the first vehicle control signal.

[0277] In a possible implementation, the upgrading the first component according to the first policy information includes:

[0278] When the user is in the car, the first component is upgraded according to the first policy information.

[0279] In a possible implementation manner, before upgrading the first component according to the first policy information, the method further includes:

[0280] Obtaining a first user instruction;

[0281] Based on the first user instruction, the first component is upgraded according to the first policy information.

[0282] Regarding the technical effects brought about by this design and any possible implementation method, please refer to the introduction of the technical effects corresponding to Figure 5 and the corresponding implementation method.

[0283] In another possible design, the upgrade device 70 may correspond to the server in the method embodiment shown in FIG. 7 . For example, the upgrade device 70 may be a server or a chip in the server. The upgrade device 70 may include components for executing the operations performed by the server in the method embodiment described above, and each component in the upgrade device 70 is configured to implement the operations performed by the server in the method embodiment described above. Specifically, the upgrade device 70 may be as follows:

[0284] generating second strategy information;

[0285] sending the second strategy information to the vehicle;

[0286] The vehicle includes a first component, the second policy information is associated with M upgrade condition checks, the M upgrade condition checks are upgrade condition checks corresponding to when the first component is not faulty, the second policy information is associated with the first policy information, the first policy information is upgrade policy information corresponding to when the first component is faulty, the first policy information is used to indicate ignoring the results of the N upgrade condition checks, or the first policy information is used to indicate ignoring the execution of the N upgrade condition checks, M is an integer greater than 0, and N is an integer greater than 0.

[0287] In a possible implementation manner, the first strategy information is determined by the vehicle or preconfigured in the vehicle.

[0288] In a possible implementation manner, the first component is a power-related component of the vehicle.

[0289] In one possible implementation, the power-related components include one or more of the following:

[0290] Battery management system BMS, microcontroller MCU, or power distribution unit PDU.

[0291] In one possible implementation, the N upgrade condition checks include one or more of the following:

[0292] Pull the high-voltage signal to check, pull the vehicle ignition signal to check, check the vehicle's power battery percentage, check the vehicle's speed, check the vehicle's gear position, check the vehicle's ignition status, check the vehicle's on-board diagnostic interface status, check whether the vehicle allows whole-vehicle upgrade or whole-vehicle flashing, check the vehicle's handbrake status, check the vehicle's fast charging gun connection status, check the vehicle's charging gun connection status, check the vehicle's fuel filler cap status, check the vehicle's battery percentage, or notify the vehicle to enter upgrade mode.

[0293] Regarding the technical effects brought about by this design and any possible implementation method, please refer to the introduction of the technical effects corresponding to Figure 5 and the corresponding implementation method.

[0294] In the upgrade device 70 described in Figure 7, when an abnormality occurs in a core component of the vehicle, the upgrade device 70 actively identifies the abnormal status information and generates a first strategy information to rescue the core component. This automatic rescue method that does not require human participation can reduce operating costs, and at the same time is conducive to improving rescue efficiency and enhancing user experience.

[0295] In the case where the upgrading device may be a chip or a chip system, reference may be made to the schematic structural diagram of the chip shown in FIG8 .

[0296] As shown in Figure 8 , chip 80 includes a processor 801 and an interface 802. There may be one or more processors 801, and there may be multiple interfaces 802. It should be noted that the functions corresponding to processor 801 and interface 802 can be implemented through hardware design, software design, or a combination of hardware and software, without limitation.

[0297] Optionally, the chip 80 may further include a memory 803 , which is used to store necessary program instructions and data.

[0298] In this application, processor 801 may be used to call from memory 803 an implementation program for the upgrade method provided in one or more embodiments of this application on one or more devices in an onboard device or server where the upgrade master control software is deployed, and execute the instructions contained in the program. Interface 802 may be used to output the execution results of processor 801. In this application, interface 802 may specifically be used to output various messages or information from processor 801.

[0299] For the upgrade method provided by one or more embodiments of the present application, please refer to the various embodiments shown in Figure 5 above, which will not be repeated here.

[0300] The processor in the embodiments of the present application may be a central processing unit (CPU), and the processor may also be other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field programmable gate arrays (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor, etc.

[0301] The memory in the embodiments of the present application is used to provide storage space, in which data such as an operating system and computer programs can be stored. The memory includes, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), or compact disc read-only memory (CD-ROM).

[0302] According to the method provided in the embodiment of the present application, the embodiment of the present application also provides a computer-readable storage medium, in which a computer program is stored. When the computer program runs on one or more processors, the method shown in Figure 5 can be implemented.

[0303] According to the method provided in the embodiment of the present application, the embodiment of the present application also provides a computer program product, which includes a computer program. When the computer program runs on a processor, it can implement the method shown in Figure 5 above.

[0304] An embodiment of the present application further provides a system, which includes at least one upgrade device 60 or upgrade device 70 or chip 80 as described above, and is used to execute the steps executed by the corresponding device in any of the embodiments of FIG. 5 .

[0305] An embodiment of the present application also provides a system, which includes a vehicle-mounted device deployed with upgraded main control software and a server. The vehicle-mounted device deployed with upgraded main control software is used to execute the steps executed by the upgraded main control software in the embodiment shown in Figure 5 above, and the server is used to execute the steps executed by the server in the embodiment shown in Figure 5 above.

[0306] An embodiment of the present application further provides a processing device, including a processor and an interface; the processor is used to execute the method in any of the above method embodiments.

[0307] It should be understood that the above-mentioned processing device can be a chip. For example, the processing device can be a field programmable gate array (FPGA), a general-purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, a discrete gate or transistor logic device, a discrete hardware component, a system on chip (SoC), a central processing unit (CPU), a network processor (NP), a digital signal processing circuit (DSP), a microcontroller unit (MCU), a programmable logic device (PLD) or other integrated chip. The various methods, steps and logic block diagrams disclosed in the embodiments of the present application can be implemented or executed. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor, etc. The steps of the method disclosed in conjunction with the embodiments of the present application can be directly embodied as being executed by a hardware decoding processor, or can be executed by a combination of hardware and software modules in the decoding processor. The software module can be located in a storage medium well-known in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, etc. The storage medium is located in the memory, and the processor reads the information in the memory and, in conjunction with its hardware, completes the steps of the above method.

[0308] It is understood that the memory in the embodiments of the present application may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memories. Among them, the non-volatile memory may be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The volatile memory may be a random access memory (RAM), which is used as an external cache. By way of example and not limitation, many forms of RAM are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), and direct RAM bus RAM (DR RAM). It should be noted that the memory of the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0309] In the above embodiments, all or part of the embodiments may be implemented by software, hardware, firmware, or any combination thereof. When implemented using software, all or part of the embodiments may be implemented in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of the present application are generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via a wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) method. The computer-readable storage medium may be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more available media integrated therein. The available medium may be a magnetic medium (eg, a floppy disk, a hard disk, a magnetic tape), an optical medium (eg, a high-density digital video disc (DVD)), or a semiconductor medium (eg, a solid state disc (SSD)).

[0310] The units in the above-mentioned various apparatus embodiments completely correspond to the electronic devices in the method embodiments, and the corresponding modules or units perform the corresponding steps. For example, the transceiver unit (transceiver) performs the receiving or sending steps in the method embodiments, and other steps except sending and receiving can be performed by the processing unit (processor). The functions of the specific units can be referred to the corresponding method embodiments. Among them, there can be one or more processors.

[0311] It is understood that in the embodiments of the present application, the electronic device can perform some or all of the steps in the embodiments of the present application. These steps or operations are merely examples, and the embodiments of the present application can also perform other operations or variations of various operations. In addition, the various steps can be performed in a different order than those presented in the embodiments of the present application, and it is possible that not all operations in the embodiments of the present application need to be performed.

[0312] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software 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 beyond the scope of this application.

[0313] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0314] In the several embodiments provided in this application, it should be understood that the disclosed systems, 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 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 system, 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.

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

[0316] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0317] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) 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.

[0318] The above is only a specific implementation method of the present application, but the scope of protection of the present application is not limited thereto. Any technician familiar with this technical field can easily think of changes or replacements within the technical scope disclosed in this application, which should be covered by the scope of protection of the present application.

Claims

1. An upgrading method, characterized in that: Applied to a vehicle, the vehicle comprising a first component, the method comprising: In the case of a failure of the first component, upgrading the first component according to first policy information, wherein the first policy information is used to indicate to ignore results of N upgrade condition checks, or the first policy information is used to indicate to ignore execution of the N upgrade condition checks, where N is an integer greater than 0; In the case that the first component is not faulty, M upgrade condition checks are performed according to the second policy information, where M is an integer greater than 0; in the case that the M upgrade condition checks are passed, the first component is upgraded, wherein passing the first upgrade condition check includes the result of the first upgrade condition check being successful, and the first upgrade condition check is any one of the M upgrade condition checks.

2. The method according to claim 1, characterized in that The first policy information is associated with the second policy information, the second policy information comes from a server, and the first policy information is determined by the vehicle or pre-configured in the vehicle.

3. The method according to claim 1 or 2, characterized in that: The method further comprises: Acquiring abnormal status information of the first component; Determine a first abnormality level according to the abnormal state information, where the first abnormality level belongs to one of multiple abnormality levels, and the multiple abnormality levels are used to describe the severity of the fault; In the case where the first component fails, upgrading the first component according to the first policy information includes: When the first abnormality level meets a preset condition, the first component is upgraded according to the first policy information.

4. The method according to any one of claims 1 to 3, characterized in that: The first component belongs to a power-related component of the vehicle.

5. The method according to claim 4, characterized in that The power-related components include one or more of the following: Battery management system BMS, microcontroller MCU, or power distribution unit PDU.

6. The method according to any one of claims 1 to 5, characterized in that: The N upgrade condition checks include one or more of the following: Pull the high-voltage signal to check, pull the vehicle ignition signal to check, check the vehicle's power battery percentage, check the vehicle's speed, check the vehicle's gear position, check the vehicle's ignition status, check the vehicle's on-board diagnostic interface status, check whether the vehicle allows whole-vehicle upgrade or whole-vehicle flashing, check the vehicle's handbrake status, check the vehicle's fast charging gun connection status, check the vehicle's charging gun connection status, check the vehicle's fuel filler cap status, check the vehicle's battery percentage, or notify the vehicle to enter upgrade mode.

7. The method according to any one of claims 1 to 6, characterized in that: The step of upgrading the first component according to the first policy information includes: The first component is upgraded at a first moment according to the first policy information.

8. The method according to claim 7, characterized in that The step of upgrading the first component according to the first policy information at the first moment includes: When the user is not in the car, the first component is upgraded according to the first policy information at the first moment.

9. The method according to claim 7 or 8, characterized in that: Before upgrading the first component according to the first policy information at the first moment, the method further includes: releasing a first vehicle control signal, where the first vehicle control signal is a signal associated with executing the M upgrade condition checks; A second vehicle control signal is activated, where the second vehicle control signal is a signal associated with the first strategy information.

10. The method according to claim 9, characterized in that The second vehicle control signal is included in the first vehicle control signal.

11. The method according to any one of claims 1 to 6, characterized in that: The step of upgrading the first component according to the first policy information includes: When the user is in the car, the first component is upgraded according to the first policy information.

12. The method according to any one of claims 1 to 11, characterized in that: Before upgrading the first component according to the first policy information, the method further includes: Obtaining a first user instruction; Based on the first user instruction, the first component is upgraded according to the first policy information.

13. An upgrading method, characterized in that: Applied to a server, the method comprises: generating second strategy information; sending the second strategy information to the vehicle; The vehicle includes a first component, the second policy information is associated with M upgrade condition checks, the M upgrade condition checks are upgrade condition checks corresponding to when the first component is not faulty, the second policy information is associated with the first policy information, the first policy information is upgrade policy information corresponding to when the first component is faulty, the first policy information is used to indicate the result of ignoring the N upgrade condition checks, or the first policy information is used to indicate ignoring the execution of the N upgrade condition checks, M is an integer greater than 0, and N is an integer greater than 0.

14. The method according to claim 13, characterized in that The first strategy information is determined by the vehicle or preconfigured in the vehicle.

15. The method according to claim 13 or 14, characterized in that The first component belongs to a power-related component of the vehicle.

16. The method according to claim 15, characterized in that The power-related components include one or more of the following: Battery management system BMS, microcontroller MCU, or power distribution unit PDU.

17. The method according to any one of claims 13 to 16, characterized in that: The N upgrade condition checks include one or more of the following: Pull the high-voltage signal to check, pull the vehicle ignition signal to check, check the vehicle's power battery percentage, check the vehicle's speed, check the vehicle's gear position, check the vehicle's ignition status, check the vehicle's on-board diagnostic interface status, check whether the vehicle allows whole-vehicle upgrade or whole-vehicle flashing, check the vehicle's handbrake status, check the vehicle's fast charging gun connection status, check the vehicle's charging gun connection status, check the vehicle's fuel filler cap status, check the vehicle's battery percentage, or notify the vehicle to enter upgrade mode.

18. An upgrading device, characterized in that: The method comprises a unit or a module for executing the method according to any one of claims 1 to 12.

19. An upgrading device, characterized in that: The method comprises a unit or a module for executing the method as claimed in any one of claims 13 to 17.

20. An upgrading device, characterized in that: include: A processor, when the processor calls the computer program or instruction in the memory, causes the method according to any one of claims 1 to 12 to be executed.

21. An upgrading device, characterized in that: include: A processor, when the processor calls the computer program or instruction in the memory, causes the method according to any one of claims 13 to 17 to be executed.

22. An upgrading device, characterized in that: comprising a logic circuit and an interface, wherein the logic circuit and the interface are coupled; The interface is used to input data to be processed, the logic circuit processes the data to be processed according to the method according to any one of claims 1 to 12 to obtain processed data, and the interface is used to output the processed data.

23. An upgrading device, characterized in that: comprising a logic circuit and an interface, wherein the logic circuit and the interface are coupled; The interface is used to input data to be processed, the logic circuit processes the data to be processed according to the method as described in any one of claims 13-17 to obtain processed data, and the interface is used to output the processed data.

24. A computer-readable storage medium, characterized in that: include: The computer-readable storage medium is used to store instructions or computer programs; when the instructions or the computer program are executed, the method according to any one of claims 1 to 12 is implemented.

25. A computer-readable storage medium, characterized in that: include: The computer-readable storage medium is used to store instructions or computer programs; when the instructions or the computer programs are executed, the method according to any one of claims 13 to 17 is implemented.

26. A computer program product, characterized in that include: instructions or computer programs; When the instructions or the computer program are executed, the method according to any one of claims 1 to 12 is performed.

27. A computer program product, characterized in that include: instructions or computer programs; When the instructions or the computer program are executed, the method according to any one of claims 13 to 17 is performed.

28. A vehicle, characterized in that: It comprises the upgrading device as claimed in claim 18, or the upgrading device as claimed in claim 20, or the upgrading device as claimed in claim 22.

29. A system, characterized in that: include: Vehicles and servers; The vehicle is used to execute the method according to any one of claims 1-18, and the server is used to execute the method according to any one of claims 13-17.

Images