Processing method and apparatus, and carrier

Abstract

The present application provides a processing method and apparatus, as well as a carrier. The method includes the steps of: determining a first procedure phase in which a failure occurs in an over-the-air (OTA) technology update process; determining a first failure type from among multiple OTA failure types based on the first procedure phase; and determining at least one processing strategy based on the first failure type. The method enables accurate evaluation of the cause of the OTA update failure in the OTA update process, assessing the impact of the OTA update failure, and providing corresponding processing strategies and suggestions.

Description

[Technical Field]

[0001]

[0001] This application claims priority to Chinese Patent Application No. 202211730493.5 entitled "Processing Method and Apparatus and Carrier", filed with the State Intellectual Property Office of China on December 30, 2022, the entire contents of which are incorporated herein by reference.

[0002]

[0002] Technical field TECHNICAL FIELD Embodiments of the present application relate to the field of intelligent vehicles, and more particularly to processing methods and apparatus and carriers. [Background technology]

[0003]

[0003] As intelligent vehicles become more widely used in daily life, users expect that intelligent vehicles and related devices can bring them a more comfortable intelligent experience. In view of this, over-the-air (OTA) technology is gradually becoming an essential basic function for intelligent vehicles. In the case of whole-vehicle OTA, software packages are pushed from the cloud to the vehicle, and functions such as software installation and / or updates can be completed in the vehicle. New functions can be added to the vehicle or existing functions of the vehicle can be optimized through OTA technology. This greatly enriches the user's intelligent experience.

[0004]

[0004] However, the OTA update procedure for the entire vehicle is complex and includes multiple procedure phases. Any exception in a procedure phase may cause a vehicle update failure, affecting the user's intelligent experience. Furthermore, each intelligent vehicle may contain dozens or even hundreds of electronic control units (ECUs), so different ECU update failures will have different impacts on the vehicle. Therefore, how to accurately identify the cause of an OTA update failure and evaluate the impact of an OTA update failure are problems that need to be solved urgently. Summary of the Invention

[0005]

[0005] The embodiments of the present application provide a processing method and apparatus, as well as a carrier, for accurately identifying the cause of an OTA update failure in the OTA update process and evaluating the impact of the OTA update failure, and provide corresponding processing strategies and suggestions.

[0006] According to a first aspect, there is provided a processing method, including: determining a first procedure phase in an over-the-air (OTA) technology update process in which a failure occurs; determining a first failure type from among a plurality of OTA failure types based on the first procedure phase; and determining at least one processing strategy based on the first failure type.

[0007] Optionally, the first failure type may include a first failure level, in other words, the carrier may determine the first failure level from among a plurality of OTA failure levels to determine at least one processing strategy.

[0008]

[0008] Optionally, at least one processing strategy may include: prompting the user to reinstall the update package, re-pushing the update task, notifying the user of the carrier outage, and the like.

[0009] In this embodiment of the present application, the carrier can determine a first failure type from among multiple OTA failure types based on the procedure phase of the OTA update failure, and determine at least one processing strategy based on the first failure type. In this way, the cause of the OTA update failure can be accurately evaluated in the OTA update process, and the impact of the OTA update failure can be evaluated to provide corresponding processing strategies and suggestions.

[0010]

[0010] Regarding the first aspect, in some implementations of the first aspect, the method further includes: prompting a user about a failure occurring in the OTA update process and at least one processing strategy.

[0011] Optionally, a message may be pushed onto the carrier's display to prompt the user about the OTA update failure and at least one handling strategy.

[0012] Optionally, the user may be audibly prompted of the OTA update failure and at least one handling strategy.

[0013]

[0013] In this embodiment of the present application, after determining the first failure type and at least one handling strategy, the carrier can prompt the user of the OTA update failure and the corresponding handling strategy in a timely manner. In this way, the user's right to know can be guaranteed throughout the OTA update process, and the user's anxiety caused by the OTA update failure can be alleviated.

[0014]

[0014] Regarding the first aspect, in some implementations of the first aspect, the method further includes: sending first instruction information to the server, the first instruction information indicating a first failure type.

[0015] Optionally, the server may include a server in charge of OTA updates and / or an operator's server, which may be deployed on an electronic device with communication and storage capabilities or on a virtual machine in the cloud.

[0016]

[0016] In this embodiment of the present application, the carrier can send first instruction information to the server to indicate a first failure type of the OTA update failure, so that the server formulates corresponding processing strategies and suggestions based on the first failure type.

[0017]

[0017] With respect to the first aspect, in some implementations of the first aspect, the first procedure phase includes one or more of an update condition check phase, an OTA mode entry phase, a flushing phase, a software startup phase, an OTA mode exit phase, and an update completion processing phase.

[0018]

[0018] Regarding the first aspect, in some implementations of the first aspect, the first procedure phase includes a flashing phase, and the step of determining a first failure type from among a plurality of OTA failure types based on the first procedure phase includes: The method includes determining a first failure type from among a plurality of OTA failure types based on the first procedure phase and the type of the faulty component.

[0019]

[0019] Optionally, the type of faulty component may include a driving-related component and a non-driving-related component.

[0020] Optionally, the type of faulty component may include a specific type of component, for example a vehicle control unit (VCU) or a motor control unit (MCU).

[0021]

[0021] In this embodiment of the present application, when an OTA update failure occurs in the flashing phase, the carrier can determine a first failure type from among multiple OTA failure types based on the procedure phase and the type of the failed component. In this way, the type of the failed component is additionally taken into consideration, so the determined first failure type is more accurate.

[0022]

[0022] Regarding the first aspect, in some implementations of the first aspect, the method further includes: a step of obtaining an error code, the error code being determined based on a second procedure phase corresponding to an electronic control unit ECU flashing fault and a cause of the ECU flashing fault; determining a first failure type from among a plurality of OTA failure types based on a first procedure phase, the step comprising: The first procedure phase includes determining a first failure type from among a plurality of OTA failure types based on the type of the faulty component and the error code.

[0023] Optionally, the second procedure phases for responding to ECU flashing failures may include: a pre-programming phase, a main programming phase, a post-programming phase, and the like.

[0024]

[0024] Optionally, based on the aforementioned error code, the carrier can determine the error type corresponding to the error code, and formulate a corresponding processing strategy based on the error type.

[0025]

[0025] In this embodiment of the present application, when an OTA update failure occurs in the flashing phase, the carrier can determine a first failure type from among multiple OTA failure types based on the procedure phase, the type of the failed component, and the error code. In this way, the first failure type can be more accurately determined, and a processing strategy can be more accurately formulated.

[0026] According to a second aspect, there is provided a processing method, the method including: receiving first indication information sent by a carrier, the first indication information indicating a first failure type, the first failure type corresponding to a first procedure phase in an OTA update process of the carrier in which a failure occurs; and prompting a user about a fault occurring in the OTA update process and at least one handling suggestion based on a first fault type.

[0027] Optionally, the first fault type may further correspond to an error code and a type of faulty component.

[0028]

[0028] Optionally, after receiving the first instruction information, the server may push a message to an application on the user's mobile phone or send a short message to the user's mobile phone to prompt the user of an error occurring in the OTA update process and at least one processing suggestion.

[0029]

[0029] Optionally, at least one processing suggestion may include: notifying the user of the carrier's non-operational status, performing a telephone follow-up with the user, providing trailer service, and the like.

[0030]

[0030] In this embodiment of the present application, after receiving the first instruction information sent by the carrier, the server can prompt the user about the failure occurring in the OTA update process and at least one processing suggestion according to the first failure type. In this way, after the OTA update failure occurs, the user's right to know can be ensured in a timely manner, and the user's anxiety caused by the OTA update failure can be alleviated.

[0031]

[0031] Regarding the second aspect, in some implementations of the second aspect, the first procedure phase includes one or more of an update condition check phase, an OTA mode entry phase, a flashing phase, a software startup phase, an OTA mode exit phase, and an update completion processing phase.

[0032] According to a third aspect, there is provided a processing apparatus, the apparatus comprising a processing unit, the processing unit comprising: Determining the first procedural phase in the over-the-air (OTA) technology update process that is experiencing a bottleneck; determining a first failure type from among a plurality of OTA failure types based on the first procedure phase; and determining at least one handling strategy based on the first fault type.

[0033]

[0033] Regarding the third aspect, in some implementations of the third aspect, the processing unit is configured to prompt the user about a failure occurring in the OTA update process and at least one processing strategy.

[0034]

[0034] Regarding the third aspect, in some implementations of the third aspect, the device further includes a transceiver unit, wherein the transceiver unit is configured to transmit first instruction information to the server, and the first instruction information indicates a first failure type.

[0035]

[0035] With respect to the third aspect, in some implementations of the third aspect, the first procedure phase includes one or more of an update condition check phase, an OTA mode entry phase, a flashing phase, a software startup phase, an OTA mode exit phase, and an update completion processing phase.

[0036]

[0036] With respect to the third aspect, in some implementations of the third aspect, the first procedure phase includes a flashing phase; and the processing unit is specifically configured to determine a first failure type from among a plurality of OTA failure types based on the first procedure phase and the type of the faulty component.

[0037]

[0037] Regarding the third aspect, in some implementations of the third aspect, the processing unit is further configured to obtain an error code, and the error code is determined based on a second procedure phase corresponding to an electronic control unit ECU flashing fault and a cause of the ECU flashing fault; and The processing unit is specifically configured to determine a first failure type from among a plurality of OTA failure types based on a first procedure phase, a type of the faulty component, and an error code.

[0038] According to a fourth aspect, there is provided a processing device, the device including: a transceiver unit and a processing unit, the transceiver unit configured to receive first indication information sent by a carrier, the first indication information indicating a first failure type, the first failure type corresponding to a first procedure phase in an OTA update process of the carrier that is experiencing a failure; and The processing unit is configured to prompt the user about a fault occurring in the OTA update process and at least one processing suggestion based on the first fault type.

[0039]

[0039] With respect to the fourth aspect, in some implementations of the fourth aspect, the first procedure phase includes one or more of an update condition check phase, an OTA mode entry phase, a flashing phase, a software startup phase, an OTA mode exit phase, and an update completion processing phase.

[0040] According to a fifth aspect, there is provided a processing device, the device including at least one processor and a memory, the at least one processor being coupled to the memory and configured to read and execute instructions in the memory, such that the device performs a method according to any one of the first aspect and an implementation form of the first aspect or the second aspect and an implementation form of the second aspect.

[0041]

[0041] According to a sixth aspect, there is provided a computer readable storage medium, the computer readable storage medium storing program code, which when executed on a computer enables the computer to perform a method according to any one of the first aspect and an implementation form of the first aspect or the second aspect and an implementation form of the second aspect.

[0042]

[0042] According to a seventh aspect, a chip is provided, the chip including a circuit, the circuit configured to perform a method according to any one of the first aspect and an implementation form of the first aspect, or the second aspect and an implementation form of the second aspect.

[0043] According to an eighth aspect, there is provided a carrier including a processing device according to any one of the implementation forms of the third aspect.

[0044] According to a ninth aspect, there is provided a server including a processing device according to any one of the implementation forms of the fourth aspect.

[0045]

[0045] According to a tenth aspect, there is provided a processing system including the carrier of the ninth aspect and the server of the tenth aspect. [Brief explanation of the drawings]

[0046] [Figure 1]

[0046] Figure 1 is a functional diagram of a carrier according to an embodiment of the present application. [Figure 2]

[0047] FIG. 2 shows a system architecture to which the processing method according to the embodiment of the present application is applicable. [Figure 3]

[0048] FIG. 3 is a schematic flowchart of a processing method according to an embodiment of the present application. [Figure 4A]

[0049] 4A to 4C are schematic flow charts of another processing method according to an embodiment of the present application. [Figure 4B] 4A to 4C are schematic flow charts of another processing method according to an embodiment of the present application. [Figure 4C] 4A to 4C are schematic flow charts of another processing method according to an embodiment of the present application. [Figure 5A]

[0050] 5A to 5E are schematic flow charts of another processing method according to an embodiment of the present application. [Figure 5B] 5A to 5E are schematic flow charts of another processing method according to an embodiment of the present application. [Figure 5C] 5A to 5E are schematic flow charts of another processing method according to an embodiment of the present application. [Figure 5D] 5A to 5E are schematic flow charts of another processing method according to an embodiment of the present application. [Figure 5E] 5A to 5E are schematic flow charts of another processing method according to an embodiment of the present application. [Figure 6(a)]

[0051] 6(a) to 6(e) are diagrams of scenarios in which processing methods according to embodiments of the present application are applicable. [Figure 6(b)]

[0051] Figures 6(a) to 6(e) are diagrams of scenarios in which processing methods according to embodiments of the present application are applicable. [Figure 6(c)]

[0051] Figures 6(a) to 6(e) are diagrams of scenarios in which processing methods according to embodiments of the present application are applicable. [Figure 6(d)]

[0051] Figures 6(a) to 6(e) are diagrams of scenarios in which processing methods according to embodiments of the present application are applicable. [Figure 6(e)]

[0051] Figures 6(a) to 6(e) are diagrams of scenarios in which processing methods according to embodiments of the present application are applicable. [Figure 7]

[0052] FIG. 7 shows a processing device according to an embodiment of the present application. [Figure 8]

[0053] FIG. 8 shows another processing apparatus according to an embodiment of the present application. DETAILED DESCRIPTION OF THE INVENTION

[0047]

[0054] In the description of the embodiments of the present application, " / " means "or" unless otherwise specified. For example, A / B may refer to A or B. In the present specification, "and / or" merely describes a relationship between related objects and indicates that three relationships may exist. For example, A and / or B may refer to the following three cases: only A is present, both A and B are present, or only B is present. In the present application, "at least one" refers to one or more, and "multiple" refers to two or more. "At least one of the following items" or similar expressions refers to any combination of these items, including any combination of a single item or multiple items. For example, at least one item of a, b, or c may refer to: a, b, c, a and b, a and c, b and c, or a, b, and c, where a, b, and c may be singular or plural.

[0048]

[0055] The prefix words "first," "second," and the like in the embodiments of the present application are intended only to distinguish different objects, and do not impose limitations on the position, order, priority, quantity, content, or the like of the described objects. The use of prefixes such as ordinal numbers used to distinguish objects described in the embodiments of the present application does not constitute limitations on the described objects. Please refer to the contextual description in the claims or embodiments for a description of the described objects. The use of such prefixes does not constitute an unnecessary limitation.

[0049]

[0056] Hereinafter, the technical solutions of the embodiments in this application will be described with reference to the accompanying drawings.

[0050]

[0057] 1 is a functional diagram of a carrier 100 according to an embodiment of the present application. It should be understood that FIG. 1 and the related description are merely examples and do not limit the carrier in the embodiment of the present application.

[0051]

[0058] Carrier 100 may include multiple subsystems, such as sensing system 120 and computing platform 130. Optionally, carrier 100 may include more or fewer subsystems, and each subsystem may include one or more components. Additionally, all subsystems and components of carrier 100 may be interconnected, either wired or wirelessly.

[0052]

[0059] The sensing system 120 may include several types of sensors for sensing information about the surrounding environment of the carrier 100. For example, the sensing system 120 may include a positioning system. The positioning system may be a global positioning system (GPS), a BeiDou system, or another positioning system. The sensing system 120 may include one or more of an inertial measurement unit (IMU), a lidar, a millimeter wave radar, an ultrasonic radar, and a camera device.

[0053]

[0060] Some or all of the functions of the carrier 100 may be controlled by a computing platform 130. The computing platform 130 may include processors 131 through 13n (n is a positive integer). A processor is a circuit having signal processing capabilities. In an implementation, a processor may be a circuit that reads instructions and executes capabilities, such as a central processing unit (CPU), a microprocessor, a graphics processing unit (GPU) (which may also be understood as a microprocessor), or a digital signal processor (DSP). In another implementation, a processor may realize a specific function based on the logical relationships of a hardware circuit. The logical relationships of the hardware circuit may be fixed or reconfigurable. For example, the processor may be a hardware circuit implemented by an application-specific integrated circuit (ASIC) or a programmable logic device (PLD), such as an FPGA. In a reconfigurable hardware circuit, the process of a processor loading a configuration document and implementing the hardware circuit configuration may be understood as the process of the processor loading instructions and implementing the functions of some or all of the aforementioned units. Alternatively, the processor may be a hardware circuit designed for artificial intelligence and may be understood as an ASIC, such as a neural network processing unit (NPU), a tensor processing unit (TPU), or a deep learning processing unit (DPU). The computing platform 130 may further include a memory configured to store instructions. Some or all of the processors 131 through 13n can invoke the instructions in the memory to perform corresponding functions.

[0054]

[0061] Computing platform 130 may control functions of carrier 100 based on inputs received from various subsystems (e.g., sensing system 120). For example, computing platform 130 may control the opening or closing of vehicle doors of the carrier based on inputs received from sensing system 120. In some embodiments, computing platform 130 may be configured to control many aspects of carrier 100 and the carrier's subsystems.

[0055]

[0062] Optionally, the above components are only examples. In actual applications, components in the above modules may be added or deleted based on actual requirements. Figure 1 should not be understood as any limitation to this embodiment of the present application.

[0056]

[0063] The carrier 100 in the present application may include a road transportation tool, a water transportation tool, an air transportation tool, an industrial device, an agricultural device, a recreational device, or the like. For example, the carrier 100 may be a vehicle. A vehicle is a broad term that includes transportation tools (e.g., commercial vehicles, passenger vehicles, motorcycles, aircraft, and trains), industrial vehicles (e.g., pallet trucks, trailers, and tractors), work vehicles (e.g., excavators, bulldozers, and cranes), agricultural equipment (e.g., lawn mowers and harvesters), recreational devices, toy vehicles, and the like. The type of vehicle is not particularly limited in the embodiments of the present application. As another example, the carrier 100 may be a transportation tool such as an aircraft or a ship.

[0057]

[0064] The following uses an example in which the carrier 100 is a vehicle to describe the technical problems that need to be solved in the present application and the technical solutions used in the present application.

[0058]

[0065] As intelligent vehicles become more widely used in daily life, users expect that intelligent vehicles and related devices can bring them a more comfortable intelligent experience. In view of this, OTA is gradually becoming an essential basic function of intelligent vehicles. In the case of whole-vehicle OTA, software packages are pushed from the cloud to the vehicle, functions such as software installation and / or updates can be completed in the vehicle, new functions can be added to the vehicle via OTA, or existing functions of the vehicle can be optimized, which greatly enriches the user's intelligent experience.

[0059]

[0066] However, the OTA update procedure for the entire vehicle is complex and involves multiple procedure phases. An exception in a procedure phase can cause a vehicle update failure and affect the user's intelligent experience. Furthermore, because each intelligent vehicle may contain dozens or even hundreds of ECUs, different ECU update failures will have different impacts on the vehicle. For example, a seat controller ECU update failure will not affect the vehicle's operation, but a battery management system (BMS) update failure will. Therefore, how to accurately identify the cause of an OTA update failure and evaluate the impact of an OTA update failure are problems that need to be solved urgently.

[0060]

[0067] FIG. 2 shows a system architecture to which the processing method according to the embodiment of the present application is applicable.

[0061]

[0068] As shown in FIG. 2, architecture 200 may include a server, a mobile phone, an OTA master control deployment node, a cockpit domain controller (CDC), and a controller area network (CAN) gateway. The server may include an OTA server or a content delivery network (CDN) server. The server may communicate with the vehicle's OTA master control module via a mobile communication network (e.g., 2G / 3G / 4G / 5G) and send an installation package to the OTA master control module to complete the OTA update. The mobile phone and the server may also communicate with each other via the mobile communication network. The server may obtain OTA update progress and update result information from the OTA master control module and push the information to the mobile phone via the mobile communication network. A user can view the progress and results of the vehicle's OTA update at any time via the mobile phone. The OTA master control deployment node may include an OTA master control module, a component installation and management module, and a CAN / unified diagnostic service (UDS) module. The OTA master control module may schedule major steps of the OTA update, classify and / or determine update exceptions, and communicate with the CDC so that relevant components in the CDC (e.g., infotainment (human-machine interaction, HMI) system, automated parking assist (APA) system, and dashboard) are updated. The component installation and management module may be configured to coordinate updates of multiple components in the vehicle and analyze the impact of component update exceptions.The CAN / Unified Diagnostic Service (UDS) communication module can be used to communicate with the CAN gateway and analyze the impact of UDS flashing procedure exceptions. The CAN gateway may be a core component in the vehicle's electronic and electrical architecture and may be used as a vehicle data exchange hub. The OTA master control deployment node can control updates to related components (e.g., seats, taillights, air conditioning) via the CAN gateway.

[0062]

[0069] In this embodiment of the present application, the server may be deployed on an electronic device with communication and storage capabilities, or may be deployed on a virtual machine in the cloud.

[0063]

[0070] 3 is a schematic flowchart of a processing method according to an embodiment of the present application. The execution entity of the method 300 may be the carrier 100. When the execution entity of the method 300 is the carrier 100, the method 300 may be executed by the computing platform 130 in the carrier 100, or may be executed by a system-on-chip (SoC) on the computing platform 130, or may be executed by a processor on the computing platform 130. Hereinafter, the method 300 will be described by using an example in which the execution entity is a carrier. The method 300 may include steps S301 to S303.

[0064]

[0071] S301: Determine the first procedure phase where a bottleneck occurs in the over-the-air (OTA) technology update process.

[0065]

[0072] Optionally, the first procedure phase may be one or more of an update condition check phase, an OTA mode entry phase, a flashing phase, a software startup phase, an OTA mode exit phase, and an update completion processing phase.

[0066]

[0073] S302: Determine a first failure type from among a plurality of OTA failure types based on a first procedure phase.

[0067]

[0074] Optionally, multiple fault types for OTA update failures may be pre-configured. For example, six fault types that may occur in the OTA update process may be pre-configured, and an appropriate fault type (first fault type) may be determined from the six fault types based on the first procedure phase, and a corresponding handling strategy may be formulated.

[0068]

[0075] Optionally, the first failure type may be a first failure level. For example, OTA update failures may be classified into six levels. The carrier may determine an appropriate failure level (first failure level) from the six failure levels based on the first procedure phase in which the OTA update failure occurs, and then formulate a corresponding processing strategy.

[0069]

[0076] In an embodiment, if the first procedure phase includes a flashing phase, in step S302, the carrier may determine a first failure type from among a plurality of OTA failure types based on the first procedure phase and the type of the faulty component. In this way, the type of the faulty component is additionally taken into consideration, so that the determined first failure type is more accurate.

[0070]

[0077] Optionally, the type of faulty component may include a driving-related component and a non-driving-related component.

[0071]

[0078] Optionally, the type of faulty component may include a specific type of component, for example, a VCU or an MCU.

[0072]

[0079] In an embodiment, if the first procedure phase includes a flashing phase, before step S302, method 300 may further include: acquiring an error code, where the error code is determined based on the second procedure phase corresponding to the electronic control unit ECU flashing failure and the cause of the ECU flashing failure. In step S302, the carrier may determine a first failure type from among multiple OTA failure types based on the first procedure phase, the type of the faulty component, and the error code. In this way, the first failure type can be more accurately determined, and a processing strategy can be more accurately formulated.

[0073]

[0080] Optionally, the second procedure phases for responding to ECU flashing failures may include: a pre-programming phase, a main programming phase, a post-programming phase, and the like.

[0074]

[0081] Optionally, based on the aforementioned error code, the carrier may determine the error type corresponding to the error code and formulate a corresponding processing strategy based on the error type.

[0075]

[0082] S303: Determine at least one handling strategy based on the first fault type.

[0076]

[0083] Optionally, at least one processing strategy may include: prompting the user to reinstall the update package, re-pushing the update task, notifying the user of the carrier outage, and the like.

[0077]

[0084] In this embodiment of the present application, the carrier can determine a first failure type from among multiple OTA failure types based on the procedure phase of the OTA update failure, and determine at least one processing strategy based on the first failure type. In this way, the cause of the OTA update failure can be accurately evaluated in the OTA update process, and the impact of the OTA update failure can be evaluated to provide corresponding processing strategies and suggestions.

[0078]

[0085] In an embodiment, after step S303, the method 300 may further include: prompting the user about a failure occurring in the OTA update process and at least one processing strategy, thereby ensuring the user's right to know throughout the OTA update process and alleviating the user's anxiety caused by an OTA update failure.

[0079]

[0086] Optionally, a message may be pushed on the carrier's display to prompt the user about the OTA update failure and at least one handling strategy.

[0080]

[0087] Optionally, the user may be audibly prompted of the OTA update failure and at least one handling strategy.

[0081]

[0088] In an embodiment, after step S303, the method 300 may include: the carrier sending first instruction information to the server, where the first instruction information indicates the first failure type. In this way, the server can formulate corresponding handling strategies and suggestions based on the first failure type.

[0082]

[0089] Optionally, the server may include a server in charge of OTA updates and / or an operator's server. The server may be deployed on an electronic device with communication and storage capabilities or on a virtual machine in the cloud.

[0083]

[0090] After receiving the first instruction information, the server may prompt the user to inform the user of the failure occurring in the OTA update process and at least one handling suggestion based on the first failure type, thereby ensuring the user's right to be informed in a timely manner after the OTA update failure occurs and alleviating the user's anxiety caused by the OTA update failure.

[0084]

[0091] For example, after receiving the first instruction information, the server may push a message to an application in the user's mobile phone or send a short message to the user's mobile phone to prompt the user about an error occurring in the OTA update process and at least one processing suggestion.

[0085]

[0092] Optionally, at least one processing suggestion may include: notifying the user of the carrier's unavailability, performing a telephone follow-up with the user, providing trailer service, and the like.

[0086]

[0093] It should be understood that in the embodiments of the present application, unless otherwise specified or there is no logical contradiction, the terms and / or descriptions in all embodiments are consistent and can be cross-referenced, and the technical features in different embodiments may be combined based on their internal logical relationships to form new embodiments.

[0087]

[0094] 4A to 4C are schematic flowcharts of another processing method according to an embodiment of the present application. Method 400 may be a specific description of steps S301 to S303 in method 300. Hereinafter, method 400 will be described by using an example in which the carrier is a vehicle. Method 400 may include two parts: vehicle exception monitoring and cloud exception monitoring.

[0088]

[0095] Vehicle exception monitoring may include the following steps:

[0089]

[0096] S401: Enable exception monitoring for the OTA main procedure in the vehicle.

[0090]

[0097] S402: Determine whether the vehicle has initiated an update installation procedure.

[0091]

[0098] Specifically, if the vehicle determines that the OTA update installation procedure has begun, step S403 may be executed; otherwise, this case may be evaluated as fault level 1.

[0092]

[0099] For example, the conclusion of a fault level 1 may be that the vehicle may continue to use older (non-updated) versions of components to process services.

[0093]

[0100] S403: Enable exception monitoring for component installation and flashing procedures.

[0094]

[0101] It should be understood that flashing may include erasing and writing. Erasing may be removing the original data in the memory of the ECU chip, and writing may be writing new data to the memory of the ECU chip.

[0095]

[0102] S404: Determine whether the component is faulty.

[0096]

[0103] Specifically, if the vehicle determines that a component has failed, step S405 may be executed; otherwise, step S411 may be executed.

[0097]

[0104] Optionally, whether a component has failed may also be understood as whether the component has failed during the installation process and / or the flashing process.

[0098]

[0105] S405: Determine whether to power on the driving-related components.

[0099]

[0106] It should be understood that power on may mean that the driving-related components are powered on, or power on may mean that the high-voltage power battery is used to power the driving-related components.

[0100]

[0107] Optionally, the driving-related components may include at least one of: a vehicle control unit (VCU), a BMS, a motor control unit (MCU), a gear shift module (GSM), a body control module (BCM), and an electronic stability controller (ESC).

[0101]

[0108] S406: Determine whether the rollback was successful.

[0102]

[0109] Specifically, in step S405, it may be determined that if the rollback is successful, the component can be started regardless of whether the driving-related component is powered on. This case is evaluated as fault level 3. Otherwise, step S407 is executed.

[0103]

[0110] For example, a conclusion for fault level 3 may be that all components of the vehicle can be started normally, the basic functions of the vehicle are normal, and the vehicle can be driven.

[0104]

[0111] It should be understood that a rollback may be the act of restoring a program or data to a previous correct state due to a program or data processing error. Types of rollback may include program rollback, data rollback, and the like.

[0105]

[0112] S407: Determine the component flushing failure type.

[0106]

[0113] Specifically, regardless of whether the driving-related component is powered on in step S405, if it is determined in step S407 that the component flushing fault type is Type 1 or Type 3, it may be determined that the component can be started. This case is evaluated as fault level 3.

[0107]

[0114] If it is determined in step S405 that the driving-related components are not powered on and the component flashing fault type is determined to be Type 2 in step S407, it may be determined that non-critical components (e.g., non-power-related components) cannot be started. This case is evaluated as fault level 4.

[0108]

[0115] If it is determined in step S405 that the driving-related components are powered on and the component flashing fault type is determined to be Type 2 in step S407, it may be determined that the critical components (e.g., power-related components) cannot be started. This case is evaluated as fault level 5.

[0109]

[0116] For example, Type 1 can indicate that a component failed before flashing but the ECU can start, Type 2 can indicate that the ECU cannot start, and Type 3 can indicate that a component failed after flashing but the ECU can start.

[0110]

[0117] For example, the conclusion of a fault level 4 may be that the vehicle can be driven normally, but some functions cannot be used.

[0111]

[0118] The conclusion of fault level 5 may be that the vehicle cannot be powered on and cannot be driven.

[0112]

[0119] If the vehicle determines in step S404 that the component is functioning properly, the following steps may be performed.

[0113]

[0120] S411: It is determined whether flushing of all components is complete.

[0114]

[0121] Specifically, the vehicle may determine whether flushing of all components is complete. If flushing is complete, step S412 may be executed; if not, step S403 may be executed again.

[0115]

[0122] S412: Exit OTA mode.

[0116]

[0123] S413: Determine whether the OTA mode has been successfully exited.

[0117]

[0124] Specifically, if the vehicle determines that it has successfully exited OTA mode, then method 400 ends. Otherwise, the case may be evaluated as fault level 3.

[0118]

[0125] Cloud exception monitoring may include the following steps:

[0119]

[0126] S421: Monitor the cloud OTA update results.

[0120]

[0127] S422: Determine whether the vehicle has not performed feedback before the timeout.

[0121]

[0128] Specifically, if the cloud does not detect the vehicle's feedback information (e.g., the progress and result of the OTA update) in the OTA update process within a preset duration, this case may be evaluated as fault level 6. Otherwise, the cloud may record the vehicle's feedback result.

[0122]

[0129] For example, the conclusion of a fault level 6 may be that the vehicle cannot be driven.

[0123]

[0130] Optionally, the cause of fault level 6 could be the inability to complete an OTA update due to the OTA update triggering the power supply.

[0124]

[0131] 5A to 5E are schematic flowcharts of another processing method according to an embodiment of the present application. Method 500 can be a specific description of steps S301 to S303 in method 300. Hereinafter, method 500 will be described by using an example in which the carrier is a vehicle. Method 500 can include the following steps:

[0125]

[0132] S501: The OTA server detects that a software package has been uploaded.

[0126]

[0133] Specifically, software packages may be uploaded manually by operations personnel or automatically via a cloud-based software repository.

[0127]

[0134] In step S501, if a fault occurs in the procedure, the user cannot recognize the fault, in other words, the fault in the procedure does not affect the user.

[0128]

[0135] S502: The OTA server detects that an operator has created a task.

[0129]

[0136] For example, the task may be an OTA update task, and the task may include one or more of a task file, a component ID, and a software package.

[0130]

[0137] S503: The OTA server pushes a task to the OTA management module.

[0131]

[0138] S504: The OTA management module pushes a task to a user agent (UA) update agent module.

[0132]

[0139] If a failure occurs in the procedure in steps S502 to S504, the user cannot recognize the failure, in other words, the failure of the procedure does not affect the user.

[0133]

[0140] S505: The OTA management module sends a request message to the power management and power on / off management module, requesting the power management and power on / off management module to sequentially wake up the vehicle, supply power to related components by using the low-voltage power supply battery, and supply power to related components by using the high-voltage power supply battery.

[0134]

[0141] In step S505, if a fault occurs in the procedure, the user cannot recognize the fault, in other words, the fault in the procedure does not affect the user.

[0135]

[0142] Optionally, step S505 may be performed if the vehicle is not powered on. If the vehicle is powered on, step S505 may be skipped and step S506 is performed immediately.

[0136]

[0143] S506: The OTA server distributes the software package to the OTA management module.

[0137]

[0144] S507: The OTA management module sends software package download instruction information to the UA update agent module.

[0138]

[0145] S508: The UA update agent module sends software package download request information to the OTA server.

[0139]

[0146] S509: The UA update agent module sends software package download information to the OTA server.

[0140]

[0147] S510: The UA update agent module sends download completion information to the OTA management module.

[0141]

[0148] For example, download completion information may indicate that a UA update agent module successfully downloaded a software package.

[0142]

[0149] If a failure occurs in the procedure at steps S506 to S510, the user will not have a clear understanding of the failure, and the failure in the procedure can then be resolved by a resumable transfer or re-download of the software package.

[0143]

[0150] S511: The UA update agent module performs software package signature verification.

[0144]

[0151] If a failure occurs in step S511, i.e., the software package signature verification fails, the software package fails to download and the vehicle cannot initiate the OTA update. However, the existing versions of the components and related software in the vehicle remain available. Therefore, even if a failure occurs in the procedure, the user's normal use of the vehicle is not affected.

[0145]

[0152] S512: The vehicle mode management module performs a prerequisite check for entering OTA mode, and if the check is successful, the vehicle enters OTA update mode and step S513 is executed.

[0146]

[0153] If a failure occurs in the procedure in step S512, the vehicle cannot initiate the OTA update, but the existing versions of the components and their associated software in the vehicle are available.

[0147]

[0154] S513: The OTA management module instructs the power management and power on / off management module to apply a high voltage and prepares high voltage flashing instruction information.

[0148]

[0155] Applying a high voltage may be understood as using a high voltage power battery to power relevant components for an OTA update.

[0149]

[0156] S514: The OTA management module sends high-voltage flashing start instruction information to the UA update agent module.

[0150]

[0157] S515: The UA update agent module sends high-voltage flashing start instruction information to the domain installation and management module.

[0151]

[0158] If a failure occurs in the procedure at steps S513 to S515, the vehicle cannot initiate the OTA update, but the existing versions of the components and their associated software in the vehicle remain available.

[0152]

[0159] S516: The domain installation and management module sends UDS flashing instruction information to the component ECU.

[0153]

[0160] Optionally, after completing the UDS flashing, the component ECU can send flashing completion information to the domain installation and management module. After receiving the flash completion information, the domain installation and management module can send high-voltage flashing completion information to the UA update agent module. After receiving the high-voltage flashing completion information, the UA update agent module can send high-voltage flashing completion information to the OTA management module.

[0154]

[0161] S517: The OTA management module instructs the power management and power on / off management module to remove the high voltage and prepares low voltage flashing instruction information.

[0155]

[0162] Removing the high voltage may be understood as using a low voltage power battery to power the relevant components in the OTA update process.

[0156]

[0163] S518: The OTA management module sends low-voltage flashing start instruction information to the UA update agent module.

[0157]

[0164] S519: The UA update agent module sends low voltage flashing start instruction information to the domain installation and management module.

[0158]

[0165] If a failure occurs in steps S516 to S519, it may be determined that the component versions do not match but the basic functionality of the vehicle is available (e.g., the vehicle's dashboard display functions normally and the vehicle can be driven normally). The component version mismatch may be understood as one part of the vehicle's components completing the OTA update while another part of the vehicle's components does not. The two parts of the components cannot cooperate with each other.

[0159]

[0166] S520: The installation program module sends UDS flashing instruction information to the component ECU.

[0160]

[0167] Optionally, after completing the UDS flashing, the component ECU can send flashing completion information to the domain installation and management module. After receiving the flashing completion information, the domain installation and management module can send low-voltage flashing completion information to the UA update agent module. After receiving the low-voltage flashing completion information, the UA update agent module can send update flashing completion information to the OTA management module.

[0161]

[0168] In step S520, if a fault occurs in the procedure, the vehicle can determine the impact of the fault based on the component in which the fault occurred and the phase in which the fault occurred. The impact of the fault can include at least one of the following: a mismatch in the component version, a failure in some function of the component but no impact on driving, an inability to power on the component, and an inability to drive the vehicle.

[0162]

[0169] Optionally, step S520 may be performed if the vehicle needs to perform low-voltage flushing. If the vehicle does not need to perform low-voltage flushing, step S520 may be skipped and step S521 is performed directly.

[0163]

[0170] S521: The UA update agent module collects update logs from the OTA management module.

[0164]

[0171] S522: The OTA management module sends OTA mode exit instruction information to the vehicle mode management module.

[0165]

[0172] S523: The power management and power on / off management module performs vehicle power off and exits OTA mode.

[0166]

[0173] In this embodiment of the present application, after a failure occurs in each step or procedural phase of the OTA update in the OTA update process, it is possible to analyze the impact on the user and help formulate a handling strategy for the OTA update failure.

[0167]

[0174] Below, we use Table 1 as an example to explain the handling strategy and analysis results of exceptions that occur in the functionality of vehicle components during the OTA update process. Table 1 [Table 1]

[0168]

[0175] As shown in Table 1, for example, if the OTA update process detects that the VCU component is functioning abnormally, the conclusion is that the vehicle cannot be powered by the high-voltage power battery and the vehicle cannot continue to be driven. Because the VCU is a driving-related component, the strategy used after the VCU is found to be functioning abnormally may be for the vehicle to prompt the user by illuminating a fault indicator or in another manner. In another example, if the OTA update process detects that the air conditioner (AC) component is functioning abnormally, the vehicle can be powered by the high-voltage power battery and the vehicle can continue to be driven, but the air conditioner cannot be used. Because the AC is a non-driving-related component, the strategy used after the AC is found to be functioning abnormally may be for the vehicle not to provide a prompt to the user. In another example, if the OTA update process detects that the GSM component is functioning abnormally, the conclusion is that the vehicle can be powered by the high-voltage power battery, but the vehicle cannot be driven or shift gears. Since the GSM is a driving-related component, the strategy used after the GSM is found to be functioning abnormally may be for the vehicle to turn on a fault indicator or to otherwise prompt the user.

[0169]

[0176] In this embodiment of the present application, in the OTA update process, an abnormal component can be analyzed to obtain an analysis result and a corresponding processing strategy, and the analysis result and the corresponding processing method are summarized in a table, so that when a component is abnormal, a table lookup process is performed.

[0170]

[0177] Below, we will explain the handling strategy when an error occurs during the flashing phase of an OTA update, using Table 2 as an example. Table 2 [Table 2]

[0171]

[0178] If a failure occurs during the flashing phase of the OTA update, the vehicle may obtain an error code. The error code may be determined based on the cause of the ECU flashing failure and the procedure phase corresponding to the ECU flashing failure. An error type may be determined based on the error code, and a failure level of the corresponding OTA update failure and a corresponding handling strategy may be further determined. The error type may include Type 1 to Type 3. Type 1 may indicate that a component is faulty before flashing but the ECU can be started. Type 2 may indicate that the ECU cannot be started. Type 3 may indicate that a component is faulty after flashing but the ECU can be started.

[0172]

[0179] For example, as shown in Table 2, when a vehicle performs an OTA update, it receives error code 00020001. This error code indicates that the programming session request response timed out. Based on the error code, the vehicle can determine that the error type is Type 1. In other words, a fault occurred before flashing, but the ECU can still be started. In this case, the vehicle can determine the corresponding fault level based on the type of the faulty component and the error type (Type 1) during the flashing process, and then determine a handling strategy corresponding to the fault level.

[0173]

[0180] In another example, as shown in Table 2, when a vehicle performs an OTA update, it receives error code 00030015. This error code indicates that the vehicle failed to exit OTA mode. Based on the error code, the vehicle can determine that the error type is Type 3. In other words, although a component is faulty after flashing, the ECU can still be started. In this case, the vehicle can determine the corresponding fault level based on the type of the faulty component and the error type (Type 3) during the flashing process, and then determine a processing strategy corresponding to the fault level.

[0174]

[0181] In this embodiment of the present application, when an error occurs in the flashing procedure of the OTA update, the vehicle can obtain an error code, determine the error type based on the error code, and further determine the corresponding failure level and corresponding handling strategy of the OTA update failure.

[0175]

[0182] Below, we use Table 3 as an example to explain the corresponding processing strategy after the fault level is determined in the OTA update process. Table 3 [Table 3] TIFF2026502987000005.tif229170

[0176]

[0183] After determining the fault level, the vehicle may use a corresponding processing strategy based on the fault level, and the vehicle may notify a server (including a cloud server and an operator server) of the fault level through signaling interaction, and the server may use a corresponding processing strategy based on the fault level.

[0177]

[0184] For example, as shown in Table 3, if the vehicle determines that the failure level in the OTA process is Level 1, the vehicle may notify the user of the OTA update failure via the large-screen HMI because there is a failure in the pre-check phase of the software package and the vehicle will not start the formal flashing process. Furthermore, the vehicle may prompt the user to reinstall the software package. When the cloud server determines that the vehicle's failure level is Level 1, it can push a message to the application (APP) on the user's mobile phone to notify the user of the vehicle's OTA update failure and provide corresponding processing suggestions.

[0178]

[0185] In another example, if the vehicle determines that the failure level in the OTA process is level 2, as shown in Table 3, the vehicle can notify the user via the large-screen HMI that the OTA update has failed but the rollback has been successful. The vehicle can also notify the user that it will re-push the update task in the background and wait for the user to download and install the update package again. When it is determined that the vehicle's failure level is level 2, the cloud server can send an SMS message to the user's mobile phone to notify the user of the vehicle's OTA update failure and provide corresponding processing suggestions. When it is determined that the vehicle's failure level is level 2, the operator server can arrange for a corresponding operator to perform a phone follow-up with the user and guide the user to reinstall the update package.

[0179]

[0186] In another example, if the vehicle determines that the OTA process failure level is level 6, as shown in Table 3, the cause may be the following: the OTA update program cannot be exited, resulting in the vehicle being unable to power up and complete the update. In this case, the vehicle cannot prompt the user through the large-screen HMI. However, the vehicle may execute processing based on the existing power-up processing strategy. If the cloud server does not detect feedback from the vehicle in the OTA update process within a preset duration, the cloud server may notify the user of this case through the mobile phone APP or SMS message, and may also notify the operator of this case. After learning this case, the operator can make a phone follow-up with the user and arrange for personnel to provide door-to-door service or trailer service.

[0180]

[0187] In this embodiment of the present application, after determining the fault level of the vehicle in the OTA update process, the vehicle, the cloud server, and the operator can take corresponding measures to prompt the user about the OTA update fault and provide corresponding handling suggestions, thereby ensuring the user's right to know in the OTA update fault process in a timely manner and effectively resolving the problems that exist in the OTA update fault process.

[0181]

[0188] 6(a) to 6(e) are diagrams of scenarios in which processing methods according to embodiments of the present application are applicable, and methods 300, 400, and 500 are applicable to this scenario.

[0182]

[0189] As shown in FIG. 6( a), an interface 600 and a function bar 610 are displayed on a vehicle's central control screen. The interface 600 includes user account login information 601 (no account logged in to the current vehicle), a Bluetooth function icon 602, a Wi-Fi function icon 603, a cellular network signal icon 604, an in-vehicle map application search box 605, a widget 606 for switching to display all applications installed in the vehicle, a widget 607 for switching to display the in-vehicle music application, a widget 608 for displaying the vehicle's remaining power and remaining driving range, and a display card 609 for the vehicle's 360-degree (°) surround view function. The in-vehicle map application search box 605 may include a "Go Home" control 6051 and a "Go to Work" control 6052, which may be configured by the user. The function bar 610 includes an icon 611 for switching to the desktop display on the central control large screen, an interior circulation icon 612, a driver's seat heating function icon 613, a driver's seat area air conditioning temperature display icon 614, a passenger seat area air conditioning temperature display icon 615, a passenger seat heating function icon 616, and a volume setting icon 617.

[0183]

[0190] FIG. 6(b) shows a graphical user interface (GUI). The GUI includes a prompt box 618 that indicates to the user whether the vehicle meets the OTA update conditions and whether to enter the OTA update procedure. When the vehicle detects that the driver has tapped the entry control in the prompt box 618, the vehicle is able to perform the OTA update. If the vehicle obtains an error code during the OTA update process, the vehicle can determine the current failure level based on the error code, the type of the faulty component, and the procedure phase of the OTA update failure, and provide a prompt to the user based on the failure level.

[0184]

[0191] For example, the vehicle may determine that the current OTA failure level is level 5, and the GUI shown in FIG. 6(c) may be displayed on the vehicle's central control large screen. The GUI includes a prompt text 619 and a voice assistant 620. The voice assistant 620 may: "A fault has occurred in the OTA update process. The fault level is level 5 and the vehicle cannot be used normally. Do not drive the vehicle." The server may indicate to the user by voice and text that the OTA update is currently being performed. After determining that the failure level is level 5, the vehicle may send information to the server to notify the server that the vehicle's current OTA failure level is level 5, and the server may push prompt information to the user's mobile phone based on the failure level. In an embodiment, the server may push prompt information to an APP on the user's mobile phone, for example, as shown in the GUI of FIG. 6(d). The GUI is a display interface on the user's mobile phone, and the display interface includes a prompt box 621 and a control 622. The model of the vehicle currently performing the OTA update, the license plate number, and the OTA update version may also be displayed on the GUI. After receiving the OTA update failure instruction information from the server, the mobile phone may inform the user via the prompt box 621, "The installation of the new version for your vehicle has failed and you will not be able to use the vehicle normally. Do not drive." In another embodiment, the server may send an SMS message to the user's mobile phone for a prompt, for example, as shown in the GUI of FIG. 6(e). The GUI is a display interface of the user's mobile phone, and the display interface includes a prompt box 623. After receiving the SMS message sent by the server, the mobile phone displays the content of the SMS message in the prompt box 623: "The installation and update of the new version (version number) for your vehicle (vehicle model - license plate number) has failed, and the vehicle cannot be used normally. Do not drive the vehicle. Please contact after-sales service at XXX (after-sales service phone number) for a solution." In addition to the two implementations mentioned above, the operator's staff can contact the user to provide door-to-door service or trailer service.

[0185]

[0192] In this embodiment of the present application, after determining the fault level of the vehicle's OTA update fault, the vehicle, the cloud, and the operator can take corresponding measures to remind the user of the OTA update fault and provide corresponding handling suggestions, thereby ensuring the user's right to know in the process of OTA update fault in a timely manner and effectively solving the problems existing in the process of OTA update fault.

[0186]

[0193] It should be understood that the application scenarios shown in Figures 6(a) to 6(d) are merely illustrative examples and should not be construed as limitations on the present application. The contents of the prompts given to the user by the vehicle and the mobile phone can be determined based on the actual application situation of the processing method.

[0187]

[0194] It should be further understood that in the embodiments of the present application, unless otherwise specified or there is no logical contradiction, the terms and / or descriptions in all embodiments are consistent and may be cross-referenced, and the technical features in different embodiments may be combined based on their internal logical relationships to form new embodiments.

[0188]

[0195] An embodiment of the present application further provides an apparatus configured to implement any one of the aforementioned methods, the apparatus including a unit configured to implement steps performed by the carrier 100 in any one of the aforementioned methods.

[0189]

[0196] FIG. 7 is a diagram of a processing device 700 according to an embodiment of the present application. The device 700 may include a transceiver unit 710, a storage unit 720, and a processing unit 730. The transceiver unit 710 is configured to receive and transmit instructions and / or data, and may also be referred to as a communication interface or a communication unit. The storage unit 720 is configured to implement corresponding storage functions and store corresponding instructions and / or data. The processing unit 730 is configured to perform data processing. The processing unit 730 can read instructions and / or data in the storage unit, such that the device 700 implements the aforementioned processing method.

[0190]

[0197] In one design, apparatus 700 may be configured to perform the operations performed by the carrier in the previous embodiments.

[0191]

[0198] The apparatus 700 may include a processing unit 730 configured to: determine a first procedure phase in an over-the-air (OTA) technology update process in which a failure occurs; determine a first failure type from among a plurality of OTA failure types based on the first procedure phase; and determine at least one handling strategy based on the first failure type.

[0192]

[0199] In a possible implementation, the processing unit 730 is further configured to prompt the user about any failures occurring in the OTA update process and at least one processing strategy.

[0193]

[0200] In a possible implementation, the apparatus 700 further includes a transceiver unit 710. The transceiver unit 710 is configured to send first indication information to the server, the first indication information indicating the first failure type.

[0194]

[0201] In a possible implementation, the first procedure phase includes one or more of an update condition check phase, an OTA mode entry phase, a flashing phase, a software startup phase, an OTA mode exit phase, and an update completion processing phase.

[0195]

[0202] In a possible implementation, the first procedure phase includes a flashing phase. The processing unit 730 is specifically configured to determine a first failure type from among a plurality of OTA failure types based on the first procedure phase and a type of the faulty component.

[0196]

[0203] In a possible implementation, the processing unit 730 is further configured to obtain an error code, the error code being determined based on a second procedure phase corresponding to an electronic control unit ECU flashing fault and a cause of the ECU flashing fault; and the processing unit 730 is specifically configured to determine a first fault type from among a plurality of OTA fault types based on the first procedure phase, the type of the faulty component, and the error code.

[0197]

[0204] In one design, apparatus 700 may be configured to perform the operations performed by the server in the previous embodiments.

[0198]

[0205] The apparatus 700 includes a transceiver unit 710 and a processing unit 730. The transceiver unit 710 is configured to receive first instruction information sent by a carrier, the first instruction information indicating a first failure type, the first failure type corresponding to a first procedure phase in which a failure occurs in an OTA update process of the carrier; and the processing unit 730 is configured to prompt a user about the failure occurring in the OTA update process and at least one processing suggestion based on the first failure type.

[0199]

[0206] In a possible implementation, the first procedure phase includes one or more of an update condition check phase, an OTA mode entry phase, a flashing phase, a software startup phase, an OTA mode exit phase, and an update completion processing phase.

[0200]

[0207] Optionally, if the device 700 is located in a carrier 100, the processing unit 730 may be the processor 131 shown in FIG.

[0201]

[0208] 8 is a diagram of another processing device 800 according to an embodiment of the present application. The device 800 may be applied to the carrier 100 of FIG.

[0202]

[0209] The device 800 includes a memory 810, a processor 820, and a communication interface 830. The memory 810, the processor 820, and the communication interface 830 are connected via an internal connection path. The memory 810 is configured to store instructions. The processor 820 is configured to execute the instructions stored in the memory 810 to control the communication interface 830 to obtain information or to enable the device 800 to perform the processing methods described above. Optionally, the memory 810 may be coupled to the processor 820 via an interface or may be integrated with the processor 820.

[0203]

[0210] It should be noted that the communication interface 830 may be a transceiver device, such as, but not limited to, a walkie-talkie, and may further include an input / output interface.

[0204]

[0211] The processor 820 stores one or more computer programs, which include instructions that, when executed by the processor 820, enable the processing device 800 to perform the processing methods in the above-described embodiments.

[0205]

[0212] In the implementation process, the steps of the aforementioned method may be performed by using an integrated logic circuit of hardware in the processor 820 or instructions in software form. The methods disclosed with reference to the embodiments of the present application may be directly executed by a hardware processor, or may be executed by a combination of hardware and software modules in the processor. The software modules may be located in a storage medium well-established in the art, such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory, an electrically erasable programmable memory, a register, or the like. The storage medium is located in the memory 810. The processor 820 reads information from the memory 810 and performs the steps of the aforementioned method in combination with the processor hardware. To avoid repetition, the details will not be described again here.

[0206]

[0213] Optionally, the communication interface 830 of FIG. 8 may implement the transceiver unit 710 of FIG. 7, the memory 810 of FIG. 8 may implement the storage unit 720 of FIG. 7, and the processor 820 of FIG. 8 may implement the processing unit 730 of FIG. 7.

[0207]

[0214] Optionally, the device 700 or the device 800 may be a computing platform, which may be an on-board computing platform or a cloud computing platform.

[0208]

[0215] Optionally, device 700 or device 800 may be located within carrier 100 of FIG.

[0209]

[0216] Optionally, device 700 or device 800 may be the computing platform 130 in the carrier of FIG.

[0210]

[0217] An embodiment of the present application further provides a computer-readable storage medium, which stores program code, and when the computer program code is executed on a computer, enables the computer to perform any one of the methods in Figures 3 to 5A to 5E.

[0211]

[0218] An embodiment of the present application further provides a computer program product, which includes a computer program that, when executed, enables a computer to perform any one of the methods in Figures 3 to 5A to 5E.

[0212]

[0219] An embodiment of the present application further provides a chip including a circuit, the circuit configured to perform any one of the methods in FIGS. 3 to 5A to 5E.

[0213]

[0220] An embodiment of the present application further provides a carrier including any of the processing devices in FIG. 7 or FIG.

[0214]

[0221] An embodiment of the present application further provides a server including any of the processing devices in FIG. 7 or FIG.

[0215]

[0222] An embodiment of the present application further provides a processing system including a carrier and a server.

[0216]

[0223] Those skilled in the art can recognize that the present application can be implemented by electronic hardware or a combination of computer software and electronic hardware in combination with the units and algorithm steps of the examples described in the embodiments disclosed herein. Whether a function is performed by hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art may use various methods to implement the described functions for each specific application, but such implementation should not be considered to go beyond the scope of the present application.

[0217]

[0224] It will be clearly understood by those skilled in the art that for convenient and concise description, for the detailed operation processes of the aforementioned systems, devices and units, please refer to the corresponding processes in the aforementioned method embodiments, and the details will not be described again here.

[0218]

[0225] In the various embodiments provided in this application, it should be understood that the disclosed systems, devices, and methods may be implemented in other manners. For example, the described device embodiments are merely examples. For example, the division into units is merely a logical and functional division, and other divisions may be used in actual implementation. For example, multiple units or components may be combined or integrated into another system, or some features may be omitted or not implemented. Furthermore, the illustrated or described mutual couplings or direct couplings or communication connections may be realized by using some kind of interface. Indirect couplings or communication connections between devices or units may be realized in electronic, mechanical, or other forms.

[0219]

[0226] The units described as separate components may or may not be physically separate, and the parts illustrated as units may or may not be physical units, and may be located in one place or distributed across multiple network units. Some or all of the units may be selected based on actual requirements to achieve the objectives of the solutions of the embodiments.

[0220]

[0227] Furthermore, the functional units in the embodiments of the present application may be integrated into one processing unit, or each of the units may exist physically alone, or two or more units may be integrated into one unit.

[0221]

[0228] When a function is realized in the form of a software functional unit and sold or used as an independent product, the function may be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application may essentially, or a part that contributes to the current art, or a part of the technical solution may be realized in the form of a software product. The software product is stored in a storage medium and includes some instructions for instructing a computing device (which may be a personal computer, a server, or a network device) to perform all or part of the steps of the method described in the embodiments of the present application. The aforementioned storage medium includes any medium capable of storing program code, such as a USB flash drive, a removable hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0222]

[0229] The above description is merely a specific implementation of the present application and does not limit the scope of protection of the present application. Any modifications or replacements that can be easily devised by those skilled in the art within the technical scope disclosed in the present application shall fall within the scope of protection of the present application. Therefore, the scope of protection of the present application shall be subject to the scope of protection of the claims.

Claims

1. 1. A processing method comprising: determining a first procedural phase in an over-the-air (OTA) technology update process in which a failure occurs; determining a first failure type from among a plurality of OTA failure types based on the first procedure phase; and determining at least one handling strategy based on the first fault type; A method comprising:

2. 10. The method of claim 1, further comprising: prompting a user about a fault occurring in the OTA update process and at least one handling strategy; A method comprising:

3. 3. The method of claim 1 or 2, further comprising: sending first instruction information to a server; wherein the first indication indicates the first failure type.

4. 4. The method according to claim 1, wherein the first procedure phase comprises: Update condition check phase, OTA mode entry phase, Flushing phase, Software startup phase, OTA mode exit phase, and Update completion processing phase The method includes one or more of the following:

5. 5. The method according to claim 4, wherein the first procedure phase includes the flashing phase, and the step of determining a first failure type from among a plurality of OTA failure types based on the first procedure phase includes: determining the first fault type from among the plurality of OTA fault types based on the first procedure phase and a type of faulty component; A method comprising:

6. 6. The method of claim 5, further comprising: obtaining an error code, the error code being determined based on a second procedure phase corresponding to an electronic control unit ECU flashing fault and a cause of the ECU flashing fault; and determining a first failure type from among a plurality of OTA failure types based on the first procedure phase includes: determining a first failure type from among a plurality of OTA failure types based on the first procedure phase, the type of the faulty component, and the error code; A method comprising:

7. In the processing method: receiving first indication information sent by a carrier, the first indication information indicating a first failure type, the first failure type corresponding to a first procedure phase in the carrier's OTA update process that is experiencing a failure; and prompting a user with a fault occurring in the OTA update process and at least one handling suggestion based on the first fault type; A method comprising:

8. 8. The method of claim 7, wherein the first procedure phase comprises: Update condition check phase, OTA mode entry phase, Flushing phase, Software startup phase, OTA mode exit phase, and Update completion processing phase The method includes one or more of the following:

9. 1. A processing apparatus comprising a processing unit, said processing unit comprising: determining a first procedural phase in an over-the-air (OTA) technology update process in which a failure occurs; determining a first failure type from among a plurality of OTA failure types based on the first procedure phase; and determining at least one handling strategy based on the first fault type; The apparatus is configured to:

10. 10. The apparatus of claim 9, The device, wherein the processing unit is configured to prompt a user about a failure occurring in the OTA update process and at least one processing strategy.

11. 11. The apparatus of claim 9 or 10, further comprising a transceiver unit; The apparatus, wherein the transceiver unit is configured to transmit first indication information to a server, the first indication information indicating the first fault type.

12. 12. The device according to claim 9, wherein the first procedure phase comprises: Update condition check phase, OTA mode entry phase, Flushing phase, Software startup phase, OTA mode exit phase, and Update completion processing phase 10. An apparatus comprising:

13. 13. The apparatus of claim 12, wherein the first procedure phase comprises the flushing phase; and the processing unit is specifically configured to determine the first failure type from among the plurality of OTA failure types based on the first procedure phase and a type of a faulty component.

14. 14. The apparatus of claim 13, The processing unit is further configured to obtain an error code, the error code being determined based on a second procedure phase corresponding to an electronic control unit ECU flashing fault and a cause of the ECU flashing fault; and the processing unit is specifically configured to determine a first failure type from among a plurality of OTA failure types based on the first procedure phase, the type of the faulty component, and the error code.

15. A processing device including a transceiver unit and a processing unit, the transceiver unit is configured to receive first indication information sent by a carrier, the first indication information indicating a first failure type, the first failure type corresponding to a first procedure phase in an OTA update process of the carrier that is experiencing a failure; and The device, wherein the processing unit is configured to prompt a user with a fault occurring in the OTA update process and at least one handling suggestion based on the first fault type.

16. 16. The apparatus of claim 15, wherein the first procedure phase comprises: Update condition check phase, OTA mode entry phase, Flushing phase, Software startup phase, OTA mode exit phase, and Update completion processing phase 10. An apparatus comprising:

17. 9. A processing device comprising a processor and a memory, the processor coupled to the memory and configured to read and execute instructions in the memory to perform the method of any one of claims 1 to 8.

18. 9. A computer-readable storage medium having stored thereon program code that, when executed on a computer, enables the computer to perform the method of any one of claims 1 to 8.

19. A chip including circuitry, said circuitry configured to perform the method of any one of claims 1 to 8.

20. A carrier comprising a processing device according to any one of claims 9 to 14.

21. A server comprising the processing device according to claim 15 or 16.

22. A processing system comprising the carrier of claim 20 and the server of claim 21.

Images