Upgrading method and device based on over-the-air technology OTA

Abstract

The embodiment of the invention provides an OTA-based upgrading method and device. The method comprises the following steps: acquiring information of a second component associated with a first component; according to the information of the second component, whether the second component meets a first condition or not is determined, and the first condition is the condition needing to be met by the second component when the first component is upgraded; and under the condition that the second component meets the first condition, upgrading the first component through the OTA. According to the OTA-based upgrading method and device provided by the embodiment of the invention, the OTA upgrading reliability can be improved, and the user experience is improved.

Description

[0001] This application is a divisional application. The application number of the original application is 202180000380.7, and the original application date is February 4, 2021. The entire content of the original application is incorporated herein by reference. Technical Field

[0002] This application relates to the field of communication technologies, and in particular, to an upgrade method and device based on Over-the-Air (OTA) technology. Background Art

[0003] Over-the-Air (OTA) technology is a technology for data downloading via a wireless network and has now been widely applied to network upgrades of devices such as smart TVs, mobile phones, tablet computers, and set-top boxes. With the development of intelligent connected vehicles, OTA online upgrade has become an important function of automobiles. Original Equipment Manufacturers (OEMs) can upgrade relevant software and firmware of automobiles through OTA, which helps OEMs reduce recall costs, quickly respond to demands, and improve user experience. However, the use of certain software packages requires dependence on relevant software or hardware to ensure the correct installation and use of the software packages.

[0004] Therefore, it is urgent to solve the problem of upgrade failure caused by mismatch of relevant software or hardware, thereby improving the reliability of OTA upgrade. Summary of the Invention

[0005] In view of this, an upgrade method and device based on Over-the-Air (OTA) technology are proposed, which can solve the problem of upgrade failure caused by mismatch of relevant software or hardware, thereby improving the reliability of OTA upgrade.

[0006] In a first aspect, an embodiment of the present application provides an OTA-based upgrade method, the method including: obtaining information of a second component associated with a first component; determining whether the second component meets a first condition according to the information of the second component, where the first condition is a condition that the second component needs to meet when upgrading the first component; and upgrading the first component through the OTA when the second component meets the first condition.

[0007] In an embodiment of the present application, when upgrading the first component, the information of the second component associated with the first component is checked; when the information of the second component meets the matching range of the information of the second component required for upgrading the first component, the first component is upgraded, thereby reducing the possibility of upgrade failure of the first component and problems such as partial function unavailability and error-proneness after upgrading the first component, improving the reliability of OTA upgrade, and enhancing user experience.

[0008] According to the first aspect, in a possible implementation, the first condition is that when upgrading the first component, the information of the second component satisfies the matching range of the information of the second component required when upgrading the first component. In this way, the flexibility and accuracy of the first condition can be improved.

[0009] According to the first aspect or a possible implementation of the first aspect, in the second possible implementation of the OTA-based upgrade method, the information of the second component is at least one of hardware information, software information, and firmware information.

[0010] According to the first aspect, in the first possible implementation, the method further includes: when the software information and / or firmware information in the information of the second component do not satisfy the first condition, upgrading the second component so that the second component satisfies the first condition.

[0011] In this way, by automatically upgrading the second component to achieve the upgrade of the first component, the OTA-based upgrade of the first component can be completed without the user's awareness, which is beneficial to improving the user experience.

[0012] According to one aspect, in a possible implementation, in the fourth possible implementation of the OTA-based upgrade method, the method further includes:

[0013] When the hardware information in the information of the second component does not satisfy the first condition, notifying the vehicle end that the upgrade fails. In this way, it is convenient for the user to understand the reason for the upgrade failure and replace the hardware.

[0014] In a second aspect, an embodiment of the present application provides an OTA-based upgrade device, and the device includes:

[0015] An acquisition module, configured to acquire information of a second component associated with a first component;

[0016] A determination module, configured to determine whether the second component satisfies a first condition according to the information of the second component acquired by the acquisition module, where the first condition is a condition that the second component needs to satisfy when upgrading the first component; a first upgrade module, configured to upgrade the first component through the OTA when the determination module determines that the second component satisfies the first condition.

[0017] According to the second aspect, in a possible implementation, the first condition is that when upgrading the first component, the information of the second component satisfies the matching range of the information of the second component required when upgrading the first component.

[0018] According to a second aspect, in a possible implementation, in a second possible implementation of the OTA-based upgrade device, the information of the second component is at least one of hardware information, software information, and firmware information.

[0019] According to a second aspect, in a possible implementation, the device further includes:

[0020] A second upgrade module, configured to upgrade the second component to make the second component meet the first condition when the software information and / or firmware information in the information of the second component does not meet the first condition.

[0021] According to a second aspect, or any possible implementation of the above second aspect, in a fourth possible implementation of the OTA-based upgrade device, the device further includes:

[0022] A notification module, configured to notify that the vehicle-end upgrade fails when the hardware information in the information of the second component does not meet the first condition.

[0023] In a third aspect, an embodiment of the present application provides an electronic device, which can execute the OTA-based upgrade method in the first aspect or one or more of the various possible implementations of the first aspect.

[0024] In a fourth aspect, an embodiment of the present application provides a computer program product, including computer-readable code, or a non-volatile computer-readable storage medium carrying the computer-readable code. When the computer-readable code runs in an electronic device, the processor in the electronic device executes the OTA-based upgrade method in the first aspect or one or more of the various possible implementations of the first aspect.

[0025] In a fifth aspect, the present application provides a software upgrade device, including a memory and a processor. The memory stores computer program instructions, and the processor runs the computer program instructions to execute the operations in the first aspect or any implementation of the first aspect above.

[0026] According to the fifth aspect, in a first possible implementation of the software upgrade device, the device further includes a transceiver, configured to receive a policy package, an upgrade package, an upgrade failure message, or information of a second component, or to send at least one of an upgrade instruction, an upgrade failure notification, etc.

[0027] The software upgrade device described in the fifth aspect above, or any implementation manner of the fifth aspect, can be applied to terminal devices in forms including but not limited to intelligent connected vehicles, robots, and smart homes. When applied to an intelligent connected vehicle, the software upgrade device can be the intelligent connected vehicle itself, or a component of the intelligent connected vehicle, such as a central gateway, a vehicle-to-internet vehicle-side communication terminal (Telematics BOX, T-box), a human-machine interaction controller (Human-Machine Interaction, HMI), a mobile data center (Mobile Data Controller, MDC), an advanced driving assistance system (Advanced Driving Assistant System, ADAS), or an electronic control unit (Electronic Control Unit, ECU), or a sub-device within the above components, or an independent device within the intelligent connected vehicle other than the above components.

[0028] In a sixth aspect, the present application provides a software upgrade device, including a memory and a processor. The memory stores computer program instructions, and the processor runs the computer program instructions to perform the operations of the first aspect or any implementation manner of the first aspect.

[0029] According to the sixth aspect, in a first possible implementation manner of the software upgrade device, the device further includes a transceiver, which is used to receive information of a second component, or is used to send at least one of an upgrade package, a policy package, an upgrade failure message, etc.

[0030] The software upgrade device described in the sixth aspect above, or any implementation manner of the sixth aspect, can be applied to the network side, for example, existing in the form of a server on the network side.

[0031] In a seventh aspect, the present application provides a terminal software upgrade system, including the software upgrade device of the fifth aspect or any implementation manner of the fifth aspect above and the software upgrade device of the sixth aspect or any implementation manner of the sixth aspect above.

[0032] In an eighth aspect, the present application provides a computer-readable storage medium, including computer instructions, which, when run by a processor, cause the software upgrade device to execute the method of the first aspect or any implementation manner of the first aspect above.

[0033] In a ninth aspect, the present application provides an electronic device, which includes a processor configured to support the electronic device to execute corresponding functions in the method provided in the first aspect. The electronic device may further include a memory for coupling with the processor to store necessary program instructions and data of the electronic device. The electronic device may further include a communication interface for the electronic device to communicate with other devices or communication networks.

[0034] In a tenth aspect, the present application provides a chip system, which includes a processor for an electronic device or a server to implement the functions involved in the above first aspect. For example, to receive or process data and / or information involved in the above method. In a possible design, the chip system further includes a memory for storing necessary program instructions and data of the electronic device or the server. The chip system may be composed of chips or may include chips and other discrete devices.

[0035] These and other aspects of the present application will become more readily apparent in the following description of the (multiple) embodiments. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] Figure 1 A schematic diagram showing a network architecture provided by an embodiment of the present application;

[0037] Figure 2 A schematic diagram showing a network architecture provided by an embodiment of the present application;

[0038] Figure 3 A schematic diagram showing the structure of an electronic device for deploying an OTA server;

[0039] Figure 4 A schematic diagram showing the structure of a Tbox;

[0040] Figure 5a A schematic diagram showing a software upgrade process;

[0041] Figure 5b A flowchart showing an OTA-based upgrade method according to an embodiment of the present application;

[0042] Figure 6 An interaction flowchart showing an OTA-based upgrade method according to an embodiment of the present application;

[0043] Figure 7 An interaction flowchart showing an OTA-based upgrade method according to an embodiment of the present application;

[0044] Figure 8 An interaction flowchart showing an OTA-based upgrade method according to an embodiment of the present application;

[0045] Figure 9The structural schematic diagram of an OTA-based upgrade device according to an embodiment of the present application is shown. Detailed implementation manners

[0046] Various exemplary embodiments, features, and aspects of the present application will be described in detail below with reference to the accompanying drawings. Identical reference numerals in the drawings denote elements having the same or similar functions. Although various aspects of the embodiments are shown in the drawings, the drawings are not necessarily drawn to scale unless otherwise specified.

[0047] The term "exemplary" used herein means "serving as an example, embodiment, or illustration". Any embodiment described as "exemplary" herein is not necessarily to be construed as superior or better than other embodiments. Hereinafter, the terms "first" and "second" are used for descriptive purposes only and cannot be construed as implying or indicating relative importance or implicitly specifying the quantity of the indicated technical features. Thus, features defined with "first" and "second" may explicitly or implicitly include one or more of such features. In the description of the embodiments of the present application, unless otherwise stated, the meaning of "a plurality" is two or more.

[0048] In addition, for better illustration of the present application, numerous specific details are given in the following detailed implementation manners. Those skilled in the art should understand that the present application can be implemented without some specific details. In some instances, methods, means, elements, and circuits well known to those skilled in the art are not described in detail so as to highlight the gist of the present application.

[0049] Figure 1 The schematic diagram of a network architecture provided by an embodiment of the present application is shown. As Figure 1 shown, the network architecture may include an Over the Air (OTA) server, a wireless communication link, and a vehicle. In one example, the vehicle can communicate with the OTA server through a mobile communication network (such as a 2G / 3G / 4G / 5G network), or can communicate with the OTA server through a Wireless Local Area Network (WLAN). The embodiments of the present application do not limit the wireless communication link.

[0050] As Figure 1As shown in the figure, the vehicle at least includes components such as a gateway (GateWay, GW), a mobile data center (Mobile DataCenter, MDC), a human-machine interaction system (Human-Machine Interaction, HMI), a telematics control unit (Telematics Control Unit, TCU), a telematics box (Telematics box, Tbox), and an electronic control unit (Electronic Control Unit, ECU).

[0051] Among them, the GW is a core component in the vehicle's electronic and electrical architecture. As the data interaction hub of the vehicle network, it can route network data such as Controller Area Network (CAN), Local Interconnect Network (LIN), and Media Oriented System Transport (MOST) network in different networks. The MDC is the intelligent in-vehicle computing platform of the vehicle, and the MDC can be used to implement the vehicle's autonomous driving function. The HMI is the vehicle's infotainment system. The TCU and Tbox are mainly used to communicate with external vehicle devices (such as mobile phones, background systems, etc.). The ECU is a dedicated microcomputer controller for vehicles. The ECU includes, but is not limited to, a vehicle integrated unit (VehicleIntegrated / Intergration Unit, VIU), a cockpit domain controller (Cockpit Domain Controller, CDC), and a vehicle domain controller (Vehicle Domain Controller, VDC), etc. In the embodiments of the present application, the first component to be upgraded includes, but is not limited to, the above-mentioned GW, MDC, HMI, TCU, Tbox, and ECU, and the first component to be upgraded can include one or more of the above-mentioned GW, MDC, HMI, TCU, Tbox, and ECU.

[0052] In the vehicle OTA upgrade, the upgrade of multiple components in the vehicle is usually involved. Therefore, an OTA management module (which can be called the OTA Master module) is required to coordinate the upgrade of these multiple components. The OTA management module can run on components such as the vehicle's GW and Tbox, and coordinate the OTA upgrade modules (which can be called the OTA Slave modules) of other components to jointly complete the vehicle upgrade.

[0053] Figure 2 The figure shows a schematic diagram of a network architecture provided by the embodiments of the present application. As Figure 2As shown in the figure, an OTA management module is deployed in the GW of the vehicle, and an OTA upgrade module is deployed in other components of the vehicle. Among them, the OTA management module can coordinate the OTA upgrade modules deployed in each component to jointly complete the vehicle OTA upgrade. Before sending messages between the OTA server and the OTA management module, the OTA management module and the OTA upgrade module need to perform some configurations, such as configuring certificates, private keys, etc. Based on the configured information, a secure channel can be established between the OTA server and the OTA management module, such as a secure channel of Hyper Text Transfer Protocol over Secure Socket layer (HTTPS), Transport Layer Security (TLS), or Datagram Transport Layer Security (DTLS), etc., so as to securely transmit information between the OTA server and the OTA management module. For example, securely transmit the policy package, upgrade package, information of the second component, and the first condition involved in the embodiments of the present application.

[0054] In the embodiments of the present application, the OTA server can be deployed on an electronic device with wireless communication function and storage function, and can also be deployed on a virtual machine (VM) or container on the cloud, where the cloud can be a cluster composed of multiple electronic devices. Figure 3 The structural schematic diagram of the electronic device for deploying the OTA server is shown.

[0055] As Figure 3 shown, the electronic device may include at least one processor 301, a memory 302, an input / output device 303, and a bus 304. The following combines Figure 3 to specifically introduce each component of the electronic device:

[0056] The processor 301 is the control center of the electronic device, which can be a single processor or a collective term for multiple processing elements. For example, the processor 301 is a CPU, or can be an Application Specific Integrated Circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of the present application, such as: one or more Digital Signal Processors (DSPs), or, one or more Field Programmable Gate Arrays (FPGAs).

[0057] Among them, the processor 301 can execute various functions of the electronic device by running or executing software programs stored in the memory 302 and calling data stored in the memory 302.

[0058] In a specific implementation, as an embodiment, the processor 301 may include one or more CPUs, such as CPU 0 and CPU 1 shown in the figure.

[0059] In a specific implementation, as an embodiment, the electronic device may include multiple processors, such as Figure 3 the processor 301 and the processor 305 shown in []. Each of these processors may be a single-core processor (single-CPU) or a multi-core processor (multi-CPU). Here, the processor may refer to one or more devices, circuits, and / or processing cores for processing data (such as computer program instructions).

[0060] The memory 302 may be a read-only memory (ROM) or other type of static storage device that can store static information and instructions, a random access memory (RAM) or other type of dynamic storage device that can store information and instructions, or an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compact discs, laser discs, optical discs, digital versatile discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium that can be used to carry or store the desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited thereto. The memory 302 may exist independently and be connected to the processor 301 through the bus 304. The memory 302 may also be integrated with the processor 301. In the embodiments of the present application, the memory may be used for policy packages and upgrade packages, etc.

[0061] The input / output device 303 is used to communicate with other devices or communication networks. For example, it is used to communicate with communication networks such as Ethernet, Radio Access Network (RAN), and Wireless Local Area Networks (WLAN). The input / output device 303 may include all or part of the baseband processor, and may also selectively include a Radio Frequency (RF) processor. The RF processor is used to transmit and receive RF signals, and the baseband processor is used to process the baseband signals converted from RF signals or the baseband signals to be converted into RF signals.

[0062] In a specific implementation, as an embodiment, the input / output device 303 may include a transmitter and a receiver. Among them, the transmitter is used to send signals to other devices or communication networks, and the receiver is used to receive signals sent by other devices or communication networks. The transmitter and the receiver may exist independently or be integrated together. In the embodiments of the present application, the input / output device may be used to transmit and receive: policy packets, upgrade packets, information of the second component, and the first condition, etc.

[0063] The bus 304 may be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, an Extended Industry Standard Architecture (EISA) bus, etc. This bus can be divided into an address bus, a data bus, a control bus, etc. For the sake of convenience of representation, Figure 3 only a thick line is used to represent it in the figure, but it does not mean that there is only one bus or one type of bus.

[0064] Figure 3 The device structure shown in the figure does not constitute a limitation on the electronic device, and may include more or fewer components than shown in the figure, or combine some components, or have different component arrangements.

[0065] In the embodiments of the present application, the Tbox component can be used to deploy both the OTA management module and the OTA upgrade module. Taking the Tbox as an example, the structure of the in-vehicle component will be described exemplarily below. Figure 4 The schematic diagram of the structure of the Tbox is shown.

[0066] Such as Figure 4As shown, the Tbox 40 includes an application layer microprocessor unit (MPU) 41 and a microcontroller unit (MCU) 42. Among them, the MPU 41 is mainly used to implement application program functions, and the MCU 42 is mainly used to control power management and access the vehicle CAN bus. The MPU 41 and the MCU 42 communicate with each other through a general-purpose input / output (GPIO) interface and a serial peripheral interface (SPI).

[0067] Among them, the MPU 41 includes a host computer 411 and a wireless communication module 412. Among them, the host computer 411 corresponds to the chip function layer, and the wireless communication module 412 corresponds to the chip wireless communication layer.

[0068] The MPU 41 may further include a microprocessor (not shown), and the microprocessor may include one or more processing units. For example, the microprocessor includes an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, a memory, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural-network processing unit (NPU), etc. Among them, different processing units may be independent devices or integrated in one or more processors. Among them, the controller may be the nerve center and command center of the MPU 41. The controller can generate operation control signals according to the instruction operation code and timing signals to complete the control of fetching instructions and executing instructions.

[0069] A memory may also be set in the microprocessor for storing instructions and data. In some embodiments, the memory in the microprocessor is a cache memory. This memory can save the instructions or data that the microprocessor has just used or reused. If the microprocessor needs to use the instruction or data again, it can directly call it from the memory. This avoids repeated accesses, reduces the waiting time of the microprocessor, and thus improves the efficiency of the system.

[0070] The microprocessor can run the OTA-based upgrade method provided by the embodiments of the present application to reduce the upgrade error rate and improve the user experience. The microprocessor can include different devices. For example, when integrating the CPU and GPU, the CPU and GPU can cooperate to execute the OTA-based upgrade method provided by the embodiments of the present application. For example, some algorithms in the OTA-based upgrade method are executed by the CPU, and another part of the algorithms are executed by the GPU to obtain a faster processing efficiency.

[0071] After the microprocessor runs the OTA-based upgrade method provided by the embodiments of the present application, the wireless communication module 412 can establish a connection with the OTA server through the antenna and transmit the upgrade package, policy package, etc. according to the OTA-based upgrade method provided by the embodiments of the present application.

[0072] The MPU 41 may further include an internal memory (not shown). The internal memory can be used to store computer-executable program code, and the executable program code includes instructions. The microprocessor executes various functional applications and data processing of the MPU 41 by running the instructions stored in the internal memory. The internal memory can include a program storage area and a data storage area. Among them, the program storage area can store the operating system, the code of the application program, etc.

[0073] The internal memory can also store one or more computer programs corresponding to the OTA-based upgrade method provided by the embodiments of the present application. The one or more computer programs are stored in the above-mentioned memory and are configured to be executed by the one or more microprocessors. The one or more computer programs include instructions, and the above instructions can be used to execute each step of the OTA-based upgrade method according to the embodiments of the present application.

[0074] The wireless communication module 412 can provide wireless communication solutions applied to the Tbox 40, including Long Term Evolution (LTE), IP Multimedia Subsystem (IMS), New Radio (NR) communication technology, or the 5th Generation Mobile Communication Technology (5G), etc. The wireless communication module 412 can include at least one filter, switch, power amplifier, low noise amplifier (LNA), etc. The wireless communication module 412 can receive electromagnetic waves by an antenna (not shown), filter, amplify, and process the received electromagnetic waves, and then transmit them to the modulation and demodulation processor for demodulation. The wireless communication module 412 can also amplify the signal modulated by the modulation and demodulation processor and convert it into electromagnetic waves through the antenna for radiation. In some embodiments, at least some functional modules of the wireless communication module 412 can be disposed in the microprocessor. In some embodiments, at least some functional modules of the wireless communication module 412 and at least some modules of the microprocessor can be disposed in the same device. In the embodiments of the present application, the wireless communication module 412 can be used for information interaction with the OTA server and other electronic devices (such as mobile phones, tablets, personal computers, etc.). For example, the wireless communication module 412 can be used for the transmission of software information, firmware information, hardware information, upgrade packages, and policy packages between the wireless communication module 412 and the OTA server. The wireless communication module 412 can also be used for the transmission of notifications that the hardware information does not meet the corresponding hardware requirements between the wireless communication module 412 and other electronic devices.

[0075] The modulation and demodulation processor can include a modulator and a demodulator. Among them, the modulator is used to modulate the low-frequency baseband signal to be transmitted into a medium-high frequency signal. The demodulator is used to demodulate the received electromagnetic wave signal into a low-frequency baseband signal. Subsequently, the demodulator transmits the demodulated low-frequency baseband signal to the baseband processor for processing. After being processed by the baseband processor, the low-frequency baseband signal is transmitted to the application processor. The application processor outputs a sound signal through an audio device (not limited to speakers, microphones, etc.), or displays an image or video through a display screen. In some embodiments, the modulation and demodulation processor can be an independent device. In other embodiments, the modulation and demodulation processor can be independent of the microprocessor and disposed in the same device as the wireless communication module 412 or other functional modules.

[0076] The MCU 42 can be connected to the in-vehicle unit through Ethernet and can also be connected to other components in the vehicle body through the CAN network, such as sensors disposed on the vehicle body.

[0077] It can be understood that the structure illustrated in the embodiments of the present application does not constitute a specific limitation on the Tbox. In other embodiments of the present application, the Tbox may include more or fewer components than those shown in the figures, or combine certain components, or split certain components, or have different component arrangements. The components shown in the figures may be implemented in hardware, software, or a combination of software and hardware.

[0078] Figure 5a Provide a schematic diagram of a software upgrade process. This process can be applied to Figure 2 the architecture shown. As Figure 5a shown, the software upgrade process includes: 1. The OTA server signs the upgrade package; 2. The OTA server distributes the signed upgrade package through a secure channel; 3. The OTA management module downloads the signed upgrade package through the secure channel; 4. The OTA management module verifies the signature of the upgrade package; 5. After the signature verification passes, the OTA management module disassembles and distributes the upgrade package to the OTA upgrade modules of the corresponding components; 6. The OTA upgrade module receives the upgrade package distributed by the OTA management module; 7. The OTA upgrade module installs and activates the upgrade package according to the instructions of the OTA management module.

[0079] In implementation, when the OTA server distributes the signed upgrade package to the OTA management module, it will also distribute a policy package to the OTA management module, and the policy package indicates the software upgrade order of each component in the vehicle. When determining to perform an upgrade operation on a certain component according to the policy package, for example, when determining to perform an upgrade operation on the first component, the OTA management module may send a software upgrade instruction to the OTA upgrade module deployed on the first component. After receiving the software upgrade instruction, the OTA upgrade module of the first component performs the installation and activation operations of the upgrade package, thereby realizing the upgrade of the first component. After the upgrade is completed, the OTA upgrade module may send a message indicating that the upgrade is completed to the OTA management module, so that the OTA management module can determine the upgrade progress. In one example, after receiving the message indicating that the upgrade of the first component is completed, the OTA upgrade module may determine to perform the software upgrade operation of another component. In another example, after receiving the message indicating that the upgrade of the first component is completed, the OTA may determine that all upgrades are completed.

[0080] However, when the first component is upgraded, the requirements of its upgrade for related components are not considered. In practice, the use of the upgrade packages of some components requires the software, hardware, or firmware of other components to meet certain conditions. For example, the new autonomous driving function may require the relevant sensors to be at specific software and hardware versions to be used. In the case where the relevant sensors are not at the specific software version and / or hardware version, even if the new autonomous driving function is upgraded, the function may not be usable. For example, it may prompt that the sensor is not detected, or report an error due to not receiving the detection data of the sensor, etc.

[0081] Therefore, the embodiment of the present application provides an OTA-based upgrade method, which can provide guarantee for component upgrade, improve the probability of successful component upgrade, and thus enhance the user experience.

[0082] The OTA-based upgrade method provided by the embodiment of the present application can not only implement the upgrade of the whole vehicle (i.e., upgrade multiple components in the vehicle based on OTA), but also implement the software upgrade of a single component in the vehicle (i.e., upgrade any one component in the vehicle based on OTA). When upgrading the whole vehicle, each component to be upgraded can be upgraded separately according to a certain upgrade sequence.

[0083] Taking the first component as the component to be upgraded as an example, the OTA-based upgrade method provided by the embodiment of the present application will be described below. Among them, the first component can be any component. The first component can be any one of the multiple components that need to be upgraded during the whole vehicle upgrade, or a single component to be upgraded. For the whole vehicle upgrade, the upgrade methods of other components that need to be upgraded are the same as that of the first component, and will not be elaborated in the embodiment of the present application.

[0084] The OTA-based upgrade method provided by the embodiment of the present application can be applied to Figure 2 the architecture shown. This method can be executed by any one of the OTA server, the OTA management module, and the OTA upgrade module.

[0085] Figure 5b The flowchart showing the OTA-based upgrade method according to the embodiment of the present application is as follows. As Figure 5b shown, this method may include:

[0086] Step S501, obtaining information of a second component associated with the first component.

[0087] In the embodiment of the present application, the first component can represent any component to be upgraded. The second component associated with the first component can represent the component that needs to meet certain conditions when upgrading the first component.

[0088] There may be one or more second components associated with the first component. The second components associated with the first component may include the first component, that is to say, the upgrade of the first component may require the first component itself to meet certain conditions. The second components associated with the first component may include other components except the first component, that is to say, the software upgrade of the first component may require other components except the first component to meet certain conditions.

[0089] Step S502, determining whether the second component meets the first condition according to the information of the second component.

[0090] In the embodiments of the present application, the conditions that the second component needs to meet when upgrading the first component can be referred to as the first conditions. That is to say, when the second component meets the first conditions, the upgrade of the first component can be achieved; when the second component does not meet the first conditions, the upgrade of the first component cannot be achieved.

[0091] In implementation, it can be determined whether the second component meets the first conditions according to the information of the second component. Among them, the information of the second component is at least one of hardware information, software information, and firmware information. Among them, the hardware information may include a hardware version number and / or a hardware model; the software information may include a software version number; the firmware information may include a firmware version number. Correspondingly, the first conditions may be that when upgrading the first component, the information of the second component meets the matching range of the information of the second component required when upgrading the first component. That is to say, when upgrading the first component, if the information of the second component meets the matching range of the information of the second component required when upgrading the first component, it indicates that the second component meets the first conditions, and at this time, the upgrade of the first component can be achieved; if the information of the second component does not meet the matching range of the information of the second component required when upgrading the first component, it indicates that the second component does not meet the first conditions, and at this time, the upgrade of the first component cannot be achieved.

[0092] In the embodiments of the present application, the matching range of the information of the second component required when upgrading the first component can be generated by an OTA server or a Content Delivery Network (CDN). In a possible implementation manner, the OTA server can determine the software version information of the first component after upgrade according to the software version information of the first component before upgrade; and generate the matching range of the information of the second component required when upgrading the first component according to the software version information of the first component after upgrade. Alternatively, the OTA server can obtain the matching range of the information of the second component required when upgrading the first component from the CDN according to the software version information of the first component after upgrade. In implementation, the matching range of the information of the second component required when upgrading the first component can be included in the first policy package for instructing the upgrade of the first component.

[0093] The matching range of the information of the second component required when upgrading the first component may involve one or more second components. For any one of the one or more second components involved, the matching range of the information of the second component required when upgrading the first component may involve one or more of the hardware information, software information, and firmware information of the second component.

[0094] In a possible implementation, the matching range of the information of the second component required for the upgrade of the first component can be the hardware information of the second component A. That is to say, when upgrading the first component, the hardware information of the second component A needs to meet the hardware information of the second component A required for the upgrade of the first component in order to achieve the upgrade of the first component.

[0095] For example, when the first component is upgraded from software version 1.0 to software version 2.0, the matching range of the information of the second component required can be: the hardware version of the second component A is 3.0 or above. If the hardware version of the second component A is 2.0 when upgrading the first component, it means that the second component A does not meet the first condition and the upgrade of the first component cannot be achieved. If the hardware version of the second component is 3.0 or 4.0 when upgrading the first component, it means that the second component A meets the first condition and the upgrade of the first component can be achieved. Assume that when the first component is upgraded from software version 1.0 to software version 2.0, the required hardware version of the second component A is 3.0, and the hardware model is 1234 or 1235. The upgrade of the first component can be achieved only when the hardware version of the second component A is 3.0 and the hardware model is one of 1234 and 1235.

[0096] In a possible implementation, the matching range of the information of the second component required for the upgrade of the first component can be the software information of the second component A. That is to say, when upgrading the first component, the software information of the second component A needs to meet the software information of the second component A required for the upgrade of the first component in order to achieve the upgrade of the first component.

[0097] For example, assume that when the software version of the second component A is below 4.0, it cannot support the upgrade of the first component from software version 1.0 to software version 2.0, while when the version of the second component A is above 6.0, it means that the software version of the first component has been upgraded to version 2.0 or above, and the software version of the first component does not need to be upgraded. That is to say, when the first component is upgraded from software version 1.0 to software version 2.0, the matching range of the information of the second component required can be: the software version of the second component A is between 4.0 and 6.0. If the software version of the second component A is 4.0, 5.0 or 6.0 when upgrading the first component, it means that the second component A meets the first condition and the upgrade of the first component can be achieved. If the software version of the second component A is below 4.0 (such as 2.0, 3.0, 3.1 or 3.22, etc.) or above 6.0 (such as 6.11, 7.0, or 8.0, etc.) when upgrading the first component, the upgrade of the first component cannot be achieved.

[0098] In a possible implementation, the matching range of the information of the second component required for upgrading the first component can be the firmware information of the second component A. That is to say, when upgrading the first component, the hardware information of the second component A needs to meet the firmware information of the second component A required for upgrading the first component in order to achieve the upgrade of the first component.

[0099] For example, when the first component is upgraded from software version 1.0 to software version 2.0, the matching range of the information of the second component required can be: the firmware version of the second component A is 4.0, 6.0 or 8.0. If the firmware version of the second component A is not one of 4.0, 6.0 and 8.0 when upgrading the first component, the upgrade of the first component cannot be achieved. Another example is that when the first component is upgraded from software version 1.0 to software version 2.0, the matching range of the information of the second component required can be: the firmware version of the second component A is not 3.0.

[0100] In a possible implementation, the matching range of the information of the second component required for upgrading the first component can be the hardware information and software information of the second component A. That is to say, when upgrading the first component, the hardware information of the second component A needs to meet the hardware information of the second component A required for upgrading the first component, and the software information of the second component A needs to meet the software information of the second component A required for upgrading the first component in order to achieve the upgrade of the first component.

[0101] For example, when the first component is upgraded from software version 1.0 to software version 2.0, the matching range of the information of the second component required can be: the hardware version of the second component A is 3.0 or 5.0, the hardware model is 1234, and the software version is 2.0 or above.

[0102] In a possible implementation, the matching range of the information of the second component required for upgrading the first component can be the hardware information and firmware information of the second component A. That is to say, when upgrading the first component, the hardware information of the second component A needs to meet the hardware information of the second component A required for upgrading the first component, and the firmware information of the second component A needs to meet the firmware information of the second component A required for upgrading the first component in order to achieve the upgrade of the first component.

[0103] For example, when the first component is upgraded from software version 1.0 to software version 2.0, the matching range of the information of the second component required can be: the hardware model of the second component A is 1234 or 1235, and the firmware version is 2.0.

[0104] In a possible implementation, the matching range of the information of the second component required for upgrading the first component can be the software information and firmware information of the second component A. That is to say, when upgrading the first component, the software information of the second component A needs to meet the software information of the second component A required for upgrading the first component, and the firmware information of the second component A needs to meet the firmware information of the second component A required for upgrading the first component, so as to realize the upgrade of the first component.

[0105] For example, when the first component is upgraded from software version 1.0 to software version 2.0, the matching range of the information of the second component required can be: the software version of the second component A is 4.0 or above, and the firmware version is 2.0.

[0106] In a possible implementation, the matching range of the information of the second component required for upgrading the first component can be the hardware information, software information and firmware information of the second component A. That is to say, when upgrading the first component, the hardware information of the second component A needs to meet the hardware information of the second component A required for upgrading the first component, the software information of the second component A needs to meet the software information of the second component A required for upgrading the first component, and the firmware information of the second component A needs to meet the firmware information of the second component A required for upgrading the first component, so as to realize the upgrade of the first component.

[0107] For example, when the first component is upgraded from software version 1.0 to software version 2.0, the matching range of the information of the second component required can be: the hardware version of the second component A is 3.0, the software version is 4.0, and the firmware version is 2.0.

[0108] In a possible implementation, the matching range of the information of the second component required for upgrading the first component can be the software information of the second component A and the hardware information of the second component B. That is to say, when upgrading the first component, the software information of the second component A needs to meet the software information of the second component A required for upgrading the first component, and the hardware information of the second component B needs to meet the hardware information of the second component B required for upgrading the first component, so as to realize the upgrade of the first component.

[0109] For example, when the first component is upgraded from software version 1.0 to software version 2.0, the matching range of the information of the second component required can be: the software version of the second component A is 2.0 or above, the hardware version of the second component B is 3.0 or above, and the hardware model of the second component B is any model other than 1234.

[0110] In a possible implementation, the matching range of the information of the second component required for the upgrade of the first component may be the firmware information and software information of the second component A, the hardware information of the second component B, and the software information, firmware information, and hardware information of the second component C. That is to say, when upgrading the first component, the firmware information and software information of the second component A need to meet the firmware information and software information of the second component A required for the upgrade of the first component respectively, the hardware information of the second component B needs to meet the hardware information of the second component B required for the upgrade of the first component, and the software information of the second component C needs to meet the software information of the second component C required for the upgrade of the first component, the firmware information of the second component C needs to meet the firmware information of the second component C required for the upgrade of the first component, and the hardware information of the second component C needs to meet the hardware information of the second component C required for the upgrade of the first component, so as to realize the upgrade of the first component.

[0111] For example, assume that the first component is an MDC. When upgrading the autonomous driving function of the MDC, the current software version of the MDC needs to be 2.0, the software version of sensor 1 in the MDC needs to be 2.0, and the hardware model of sensor 2 is XXXX. When the MDC is used as the first component, the second components associated with the first component include the MDC, sensor 1, and sensor 2. The matching range of the information of the second component required for the upgrade of the first component is: the software information of the MDC, the software information of sensor 1, and the hardware information of sensor 2. When upgrading the MDC, when the software information of the MDC meets the software version of the MDC being 2.0, the software information of sensor 1 meets the software version of sensor 1 being 2.0, and the hardware information of sensor 2 meets the hardware model of sensor 2 being XXXX, it indicates that the second components associated with the MDC meet the first condition and the upgrade of the MDC can be realized.

[0112] It can be understood that the above examples are only for illustration, and the first component can be any component in the vehicle, and the embodiments of the present application are not limited thereto.

[0113] Step S503, when the second component meets the first condition, upgrade the first component through OTA.

[0114] Optionally, when the second component meets the first condition, the upgrade package of the first component can be downloaded, installed, and activated from the OTA server or CDN through OTA, so as to upgrade the first component.

[0115] In an embodiment of the present application, when upgrading the first component, the information of the second component associated with the first component is checked; when the information of the second component meets the matching range of the information of the second component required for the upgrade of the first component, the first component is upgraded, thereby reducing the possibility of the failure of the upgrade of the first component and the problems such as partial function unavailability and error-proneness after the upgrade of the first component, improving the reliability of the OTA upgrade, and enhancing the user experience.

[0116] It is considered that the information of the second component can be at least one of hardware information, software information, and firmware information. Therefore, the matching range of the information of the second component required for the upgrade of the first component may involve one or more of hardware information, software information, and firmware information. Among them, the software information and firmware information can be changed by upgrading the second component, and the hardware information can only be changed by replacing the hardware of the second component.

[0117] In a possible implementation manner, when the software information and / or firmware information in the information of the second component do not meet the first condition, the second component can be upgraded to make the second component meet the first condition. After meeting the first condition, the first component is upgraded.

[0118] In the first condition, the matching range of the information of the second component required for the upgrade of the first component may include software information and / or firmware information. When the software information and / or firmware information of the second component do not meet the above first condition, the second component can be upgraded so that the information of the upgraded second component meets the matching range of the information of the second component required for the upgrade of the first component, thereby making the upgraded second component meet the first condition. After that, the first component can be upgraded through OTA.

[0119] In this way, it can be ensured that when the first component is upgraded, the associated second component meets the first condition, thereby reducing the possibility of upgrade errors and enhancing the user experience. At the same time, by upgrading the second component first and then the first component when the software information and / or firmware information in the information of the second component do not meet the first condition, the probability of successful upgrade of the first component can be increased, which is beneficial to the upgrade of the first component.

[0120] It can be understood that in an embodiment of the present application, if the information of the upgraded second component still cannot meet the matching range of the information of the second component required for the upgrade of the first component, then the first component cannot be upgraded. When the second component still cannot meet the first condition after one or more upgrades of the second component, the vehicle end can be notified of the upgrade failure for the user to troubleshoot.

[0121] In a possible implementation manner, when the hardware information in the information of the second component does not meet the first condition, the vehicle end is notified of the upgrade failure.

[0122] In the first condition, the matching range of the information of the second component required for the upgrade of the first component may include hardware information. When the hardware information of the second component does not meet the above first condition, upgrading the software of the second component cannot make the second component meet the first condition, and it is necessary to replace the hardware of the second component to make the second component meet the first condition. Therefore, when the hardware information in the information of the second component does not meet the first condition, it is possible to notify the vehicle end that the upgrade fails, so as to facilitate the user to replace the hardware.

[0123] In this way, the possibility of upgrade errors can be reduced, and the user can be prompted with the reason for the inability to upgrade, thereby improving the user experience.

[0124] Optionally, when the software information and / or firmware information in the information of the second component do not meet the first condition, and the hardware information in the information of the second component does not meet the first condition, the second component may not be upgraded temporarily, and the vehicle end may be directly notified that the upgrade fails, which can save time and workload.

[0125] Figure 5b The method shown can be executed by any one of the OTA server, the OTA management module, and the OTA upgrade module. When Figure 5b the method shown is executed by the OTA server, the interaction process among the OTA server, the OTA management module, and the OTA upgrade module can be referred to Figure 6 . When Figure 5b the method shown is executed by the OTA management module, the interaction process among the OTA server, the OTA management module, and the OTA upgrade module can be referred to Figure 7 . When Figure 5b the method shown is executed by the OTA upgrade module, the interaction process among the OTA server, the OTA management module, and the OTA upgrade module can be referred to Figure 8 .

[0126] Next, in combination with Figure 6 the process of the OTA server executing Figure 5b the method shown will be described. Figure 6 The interaction flow chart showing the OTA-based upgrade method according to an embodiment of the present application is shown. As Figure 6 shown, the OTA-based upgrade method includes:

[0127] Step S601, the OTA management module collects the software information, firmware information, and hardware information of each component in the vehicle.

[0128] Among them, the software information may include the software version number, the firmware information may include the firmware version number, and the hardware information may include the hardware model and / or the hardware version number. The components in the vehicle include but are not limited to Figure 2The components shown. The OTA management module can be deployed in the GW (as shown in Figure 2 shown), or can be deployed in other components (not shown), such as in the Tbox. The embodiments of the present application do not limit this. In one example, the OTA management module can send a message for collecting information of components to the OTA upgrade modules deployed in each component. After receiving the message for collecting information of software and hardware components, the OTA upgrade module deployed in each component can return one or more of the software information, firmware information, and hardware information of the component where it is located to the OTA management module.

[0129] Step S602, the OTA management module reports the software information, firmware information, and hardware information of each component to the OTA server.

[0130] After the OTA management module confirms that each OTA upgrade module has completed information reporting, it can report the information of each component collected to the OTA server. In one example, the OTA management module can send the identifiers of each component, and the information associated with each identifier, to the OTA server. Among them, the identifier of the component can be used to identify a unique component. The identifier of the component can include the name of the component, the number of the component, or the address of the component, etc. The present application does not limit this.

[0131] In a possible implementation manner, the OTA management module can collect information of each component in the vehicle and report the information of each component to the OTA server when establishing a wireless communication link with the OTA server or when receiving an indication of the reporting information sent by the OTA server. The OTA management module can also periodically collect information of each component in the vehicle, and when establishing a wireless communication link with the OTA server or when receiving an indication of the reporting information sent by the OTA server, report the information of each component currently collected to the OTA server. In the embodiments of the present application, there is no limitation on the timing for the OTA management module to collect information of each component and report information of each component.

[0132] Step S603, the OTA server obtains the first policy package corresponding to the first component.

[0133] Among them, the first policy package can be used to represent the policy package corresponding to the first component. The first policy package can be used to indicate upgrading the first component.

[0134] Optionally, the first policy package includes a first condition, that is, when upgrading the first component, the conditions that the second component associated with the first component needs to meet. In implementation, in the first policy package, it can include the identifier of the second component associated with the first component, and the first condition. In this way, the OTA server can, according to the identifier of the second component, find out the information of the second component associated with the first component from the information of each component reported by the OTA management module.

[0135] In an application, the first policy package may further include upgrade conditions, upgrade types, upgrade sequences, user notification policies, upgrade package sizes, and upgrade package download addresses, etc. Among them, the upgrade conditions may include: the vehicle is not in the following states: emergency event handling state, the engine is in a working state, the storage space is insufficient, the remaining traffic is lower than a preset traffic threshold, etc. When the vehicle is in any of the above states, problems such as download endpoints are likely to occur during the upgrade package download process, which may lead to the failure of the upgrade package download. The upgrade types may include: silent (upgrade without notifying the user), regular (upgrade after the user agrees), and forced (upgrade without the user's consent after notifying the user). The upgrade sequence may indicate the time sequence of upgrading different components. For example, when upgrading the autonomous driving function for the MDC, the sensors need to be upgraded first (in the case where the software versions of multiple sensors need to be upgraded, the sensors can be upgraded simultaneously or in a certain time sequence). Then the MDC is upgraded. The size of the upgrade package is generally several megabytes to more than ten megabytes. The upgrade package download address may point to the OTA server or the Content Delivery Network (CDN). That is to say, the upgrade package can be downloaded from the OTA server or the CDN server.

[0136] In implementation, the OTA server may determine the software version information of the first component after the upgrade based on the software version information of the first component before the upgrade, and obtain the upgrade package of the first component or the download address of the upgrade package of the first component from the software repository according to the software version information of the first component after the upgrade. The OTA server may generate the first policy package based on the software version information of the first component before the upgrade and the software version information of the first component after the upgrade. Of course, the above first policy package may also be generated by the software repository based on the software version information of the first component before the upgrade and the software version information of the first component after the upgrade, and the OTA server may obtain the first policy package from the software repository. In the embodiments of the present application, the generation method of the first policy package is not limited.

[0137] Step S604: The OTA server searches for the information of the second component associated with the first component according to the identifier of the second component in the first policy package.

[0138] The first policy package may include the identifiers of one or more second components. Since the OTA server obtains the information of each component in the vehicle through steps S601 and S602. Therefore, the OTA server can respectively search for the information of each second component associated with the first component in the obtained information according to the identifiers of the second components.

[0139] The information of the second component found in this step may include one or more of software information, firmware information, and hardware information. The content of the specific information to be found may be determined according to the matching range indicated in the first condition. For example, if the matching range of the second component A indicated in the first condition is software information and firmware information, then the information of the second component found is the software information and firmware information of the second component A. Another example is that if the matching range of the second component B indicated in the first condition is software information and hardware information, then the information of the second component found is the software information and firmware information of the second component B. Of course, in this step, the software information, firmware information, and hardware information of the second component can all be found, and when subsequently determining whether the second component meets the first condition, the required information can be selected for matching.

[0140] Step S605, the OTA server determines whether the second component meets the first condition according to the information of the second component found.

[0141] Among them, the first condition is that when upgrading the first component, the information of the second component meets the matching range of the information of the second component required when upgrading the first component. It can be understood that there may be one or more second components associated with the first component. For each second component, there is a matching range of the information of the second component required when upgrading the first component.

[0142] For each second component: through step S603, the OTA server can obtain the matching range (i.e., the first condition) of the information of the second component required when upgrading the first component, and through step S604, the OTA server can obtain the information of the second component. Based on this, in this step, the OTA server can determine whether the second component meets the first condition according to the information of the second component. When the information of the second component meets the matching range of the information of the second component required when upgrading the first component, it can be determined that the second component meets the first condition.

[0143] It can be understood that when all the second components meet the first condition, it can be determined that the second components associated with the first component meet the first condition.

[0144] In the case where the second components associated with the first component meet the first condition, it indicates that the first component has the condition for upgrading, and the first component can be upgraded. At this time, steps S606 to S608 can be executed.

[0145] Step S606, the OTA server sends the first policy package to the OTA management module.

[0146] Step S607, when the first policy package instructs to execute the upgrade operation of the first component, the OTA management module sends an upgrade instruction to the OTA upgrade module deployed on the first component.

[0147] Among them, the upgrade instruction is used to instruct the OTA upgrade module to perform an upgrade operation, specifically to install and activate the upgrade package.

[0148] In one example, the first policy package includes upgrade conditions, upgrade types, and upgrade sequences. The upgrade condition is that the engine is not in a working state, the upgrade type is silent, and the upgrade sequence is the first upgrade. After receiving the first policy package, the OTA management module parses the first policy package. If it determines that the current engine is not in a working state, the OTA management module can determine that the upgrade operation of the first component needs to be performed currently. At this time, the OTA management module can send an upgrade instruction to the OTA upgrade module deployed on the first component.

[0149] Step S608: After receiving the upgrade instruction, the OTA upgrade module upgrades the first component.

[0150] In a possible implementation manner, the upgrade instruction sent in step S607 may include the upgrade package of the first component. In step S608, after receiving the upgrade instruction, the OTA upgrade module can obtain the upgrade package of the first component from the upgrade instruction, install and activate the upgrade package of the first component to upgrade the first component. It should be noted that the upgrade package of the first component here may be sent to the OTA management module by the OTA server when sending the first policy package in step S606, or may be downloaded by the OTA management module according to the download address in the first policy package (from the OTA server or CDN) after receiving the first policy package.

[0151] In a possible implementation manner, the upgrade instruction sent in step S607 may include the download address of the upgrade package of the first component. In step S608, after receiving the upgrade instruction, the OTA upgrade module can obtain the download address of the upgrade package of the first component from the upgrade instruction, download the upgrade package of the first component according to this download address (from the OTA server or CDN), install and activate the upgrade package of the first component to upgrade the first component.

[0152] The embodiment of the present application realizes the upgrade of the first component through OTA, and the embodiment of the present application does not limit the method of obtaining the upgrade package of the first component.

[0153] The information of the second component can be at least one of hardware information, software information, and firmware information. The second component not meeting the first condition may be caused by the software information and / or firmware information of the second component not meeting the software information and / or firmware information of the second component required for upgrading the first component, or may be caused by the hardware information of the second component not meeting the hardware information of the second component required for upgrading the first component, or may also be caused by both the software information and / or firmware information, and the hardware information of the second component not meeting the software information and / or firmware information, and the hardware information of the second component required for upgrading the first component. In the case where the software information and / or firmware information does not meet the requirements, the second component can be upgraded so that the software information and / or firmware information of the second component meets the software information and / or firmware information of the second component required for upgrading the first component, thereby enabling the second component to meet the first condition. In the case where the hardware information does not meet the requirements, however, the hardware needs to be replaced to upgrade the first component. The interaction processes in the above two cases will be described separately below.

[0154] In the case where the software information and / or firmware information in the information of the second component does not meet the first condition, it indicates that the first component can only be upgraded after the second component is upgraded. At this time, steps S609 to S613 can be executed.

[0155] Step S609, the OTA server obtains the upgrade package of the second component whose software information and / or firmware information does not meet the first condition, and the second policy package corresponding to the second component.

[0156] Here, for any second component associated with the first component: when the matching range of the information of the second component required for upgrading the first component includes software information and / or firmware information, and when upgrading the first component, the software information and / or firmware information of the second component does not meet the software information and / or firmware information of the second component indicated in the first condition required for upgrading the first component, it indicates that the software information of the second component does not meet the first condition, and the second component can be determined as the second component whose software information and / or firmware information does not meet the first condition.

[0157] For the second component whose software information and / or firmware information does not meet the first condition, the second component needs to be upgraded first so that the software information and / or firmware information of the second component meets the first condition, thereby enabling the second component associated with the first component to meet the first condition. Therefore, the OTA server can obtain the upgrade package of the second component whose software information and / or firmware information does not meet the first condition to upgrade the second component.

[0158] The second policy package can be used to represent the policy package corresponding to the second component. The second policy package can be used to indicate the upgrade of the second component. The second policy package includes the upgrade order among the second components, and the OTA management module can indicate different second components to be upgraded according to this upgrade order.

[0159] In a possible implementation, the second policy package may further include the identifier of the third component associated with the second component, and the second condition. Among them, the third component associated with the second component can represent the component that needs to meet certain conditions when upgrading the second component. In the embodiments of the present application, the conditions that the third component needs to meet when upgrading the second component can be referred to as the second condition. That is to say, when the third component meets the second condition, the upgrade of the second component can be realized, and when the third component does not meet the second condition, the upgrade of the second component cannot be realized. The second condition can be that when upgrading the second component, the information of the third component meets the matching range of the information of the third component required for the upgrade of the second component. The second condition can refer to the first condition, which will not be elaborated here.

[0160] In a possible implementation, the second policy package may further include upgrade conditions, upgrade types, upgrade orders, user notification policies, upgrade package sizes, and upgrade package download addresses, etc. The second policy package can refer to the first policy package, which will not be elaborated here.

[0161] Step S610, the OTA server sends the first policy package, the upgrade package of the second component, and the second policy package to the OTA management module.

[0162] Step S611, when the second policy package indicates to execute the upgrade operation of the second component, the OTA management module uses the upgrade package of the second component to upgrade the second component whose software information and / or firmware information does not meet the first condition, so that the second component meets the first condition.

[0163] When the software information and / or firmware information of the second component meets the first condition, it indicates that the first component has the condition for software upgrade, and the first component can be upgraded.

[0164] Step S612, when the first policy package indicates to execute the upgrade operation of the first component, the OTA management module sends an upgrade instruction to the OTA upgrade module deployed on the first component.

[0165] Step S613, after receiving the upgrade instruction, the OTA upgrade module upgrades the first component.

[0166] Step S612 and step S613 can refer to step S607 and step S608, which will not be elaborated here.

[0167] It can be understood that in the embodiments of the present application, the process of upgrading the second component needs to be completed before upgrading the first component, so that the first component can be successfully upgraded.

[0168] When the hardware information in the information of the second component does not meet the first condition, it indicates that the hardware needs to be replaced to implement the function of the upgraded first component. At this time, steps S614 and S615 can be executed to facilitate the user to understand the situation and improve the user experience.

[0169] Step S614, the OTA server sends an upgrade failure message to the OTA management module.

[0170] In one example, the upgrade failure message may include the identifier of the second component whose hardware information does not meet the first condition, the current hardware version number and / or hardware model, and the required hardware version number and / or hardware model.

[0171] Step S615, after receiving the upgrade failure message, the OTA management module notifies the user.

[0172] After receiving the upgrade failure message, the OTA management module can notify the user which component's hardware does not meet the hardware requirements, what the current hardware information of this component is, and what the hardware requirements for the upgrade are. In one example, the content of the notification may refer to the content of the upgrade failure message in step S614. In one example, the OTA management module can notify the user through the in-vehicle human-machine interaction system (such as the audio-visual system), and can also send the notification to the terminal device (such as a mobile phone, a laptop, etc.) that has established a communication connection with components such as the Tbox. The terminal device displays the notification to the user.

[0173] The OTA-based upgrade method provided by the embodiments of the present application checks whether the second component associated with the first component meets the first condition when upgrading the first component, so as to increase the possibility of successful installation and activation of the upgrade package of the first component, reduce the upgrade error rate, and improve the user experience.

[0174] At the same time, the OTA server can perform the check on the second component without modifying the logic of the OTA management module, reducing the requirements for the OTA management module.

[0175] The following will be combined with Figure 7 to describe the process of the method executed by the OTA management module Figure 5b as shown. Figure 7 An interaction flowchart showing the OTA-based upgrade method according to an embodiment of the present application is shown. As Figure 7 shown, the OTA-based upgrade method includes:

[0176] Step S701: The OTA management module collects the software information, firmware information, and hardware information of each component in the vehicle.

[0177] Considering that the OTA management module needs to determine whether the second component meets the first condition based on one or more of the software information, firmware information, and hardware information of the second component associated with the first component, the OTA management module needs to collect the software information, firmware information, and hardware information of each component in the vehicle.

[0178] Step S702: The OTA management module reports the software information and / or firmware information of each component to the OTA server.

[0179] Considering that when the OTA server obtains or generates a policy package and an upgrade package, it needs to use the software information and / or firmware information of the component. Among them, when performing software upgrade, software information is required, and when performing firmware upgrade, firmware information is required. Therefore, here the OTA management module needs to report the software information and / or firmware information of each component to the OTA server. Considering that the OTA server does not need to check the hardware of the second component, the OTA management module does not need to report the hardware information of each component to the OTA server to save the communication resources between the OTA management module and the OTA server and the storage resources of the OTA server.

[0180] Step S703: The OTA server obtains the first policy package corresponding to the first component.

[0181] Step S703 can refer to Step S603 and will not be elaborated here.

[0182] Step S704: The OTA server sends the first policy package to the OTA management module.

[0183] Since the OTA server does not perform the check on whether the second component meets the first condition, after the OTA server obtains the first policy package, it can directly send the first policy package to the OTA management module.

[0184] Step S705: The OTA management module searches for the information of the second component associated with the first component according to the identifier of the second component in the first policy package.

[0185] Since in Step S701, the OTA management module has collected the information of each component in the vehicle. Therefore, the OTA management module can search for the information of each second component associated with the first component in the collected information according to the identifiers of each second component. In this step, the information of the second component found can be one or more of software information, firmware information, and hardware information. This step can refer to Step S604 and will not be elaborated here.

[0186] Step S706: The OTA management module determines whether the second component meets the first condition according to the information of the second component found.

[0187] Step S706 can refer to Step S605, which will not be elaborated here.

[0188] When the second component associated with the first component meets the first condition, it indicates that the first component has the condition for upgrade. The first component can be upgraded. At this time, Step S707 and Step S708 can be executed.

[0189] Step S707: When the first policy package instructs to perform the upgrade operation of the first component, the OTA management module sends an upgrade instruction to the OTA upgrade module deployed on the first component.

[0190] Step S708: After receiving the upgrade instruction, the OTA upgrade module upgrades the first component.

[0191] Step S707 and Step S708 can refer to Step S607 and Step S608, which will not be elaborated here.

[0192] When the software information and / or firmware information in the information of the second component do not meet the first condition, it indicates that the first component can be upgraded only after the second component is upgraded. At this time, Step S709 to Step S713 can be executed.

[0193] Step S709: The OTA management module sends a first request to the OTA server. The first request is used to request to upgrade the second component.

[0194] In an example, the first request includes the identifier of one or more second components, and the current software version information and the required software version information of each second component (which can be obtained from the first condition).

[0195] Step S710: In response to the first request, the OTA server returns the upgrade package of the second component and the second policy package corresponding to the second component to the OTA management module.

[0196] After receiving the first request, the OTA server can obtain the upgrade packages and policy packages of each second component from the software repository according to the required software version information and the current software version information of each second component.

[0197] Step S711: When the second policy package instructs to perform the upgrade operation of the second component, the OTA management module upgrades the second component whose software information and / or firmware information do not meet the first condition by using the upgrade package of the second component, so that the second component meets the first condition.

[0198] In one example, the OTA management module may send an upgrade instruction to the OTA upgrade modules deployed for each second component according to the upgrade order indicated by the second policy package. After receiving the upgrade instruction, the OTA upgrade module deployed for the second component may upgrade the second component. The method for upgrading the software of the second component may refer to the method for upgrading the software of the first component, which will not be elaborated here.

[0199] Step S711 may refer to step S611, which will not be elaborated here.

[0200] Step S712, when the first policy package instructs to execute the upgrade operation of the first component, the OTA management module sends an upgrade instruction to the OTA upgrade module deployed for the first component.

[0201] Step S713, after receiving the upgrade instruction, the OTA upgrade module upgrades the first component.

[0202] Step S712 and step S713 may refer to step S607 and step S608, which will not be elaborated here.

[0203] In the case where the hardware information in the information of the second component does not meet the first condition, it indicates that the hardware needs to be replaced to implement the functions of the upgraded first component. At this time, step S714 may be executed.

[0204] Step S714, the OTA server sends an upgrade failure notice to the user.

[0205] In one example, the upgrade failure notice sent in this step may include the identifier of the second component whose hardware information does not meet the first condition, the current hardware version number and / or hardware model, and the required hardware version number and / or hardware model. In one example, the OTA management module may notify the user through the in-vehicle human-machine interaction system (such as an audio and video system), and may also send the notice to an electronic device (such as a mobile phone, a laptop, etc.) that has established a communication connection with components such as the Tbox. The electronic device displays the notice to the user.

[0206] The OTA-based upgrade method provided by the embodiments of the present application checks whether the second component meets the first condition according to the information of the second component associated with the first component when upgrading the first component, so as to ensure the successful installation and activation of the upgrade package of the first component, reduce the upgrade error rate, and improve the user experience.

[0207] At the same time, the OTA management module checks whether the second component meets the first condition, which can reduce the workload of the OTA server and is beneficial to OTA upgrades for multiple vehicles (such as a vehicle group) simultaneously.

[0208] The following combines Figure 8 for the OTA upgrade module to execute Figure 5bDescribe the process of the method shown. Figure 8 The interaction flowchart of the OTA-based upgrade method according to an embodiment of the present application is shown. As Figure 8 shown, the OTA-based upgrade method includes:

[0209] Step S801, the OTA management module collects software information and firmware information of each component in the vehicle.

[0210] Step S802, the OTA management module reports the software information and / or firmware information of each component to the OTA server.

[0211] Considering that neither the OTA management module nor the OTA server needs to check the hardware of the second component, therefore, the OTA management module does not need to collect the hardware information of each component in the vehicle, nor report the hardware information of each component to the OTA server.

[0212] Step S803, the OTA server obtains the first policy package corresponding to the first component.

[0213] Step S803 can refer to step S603, which will not be elaborated here.

[0214] Step S804, the OTA server sends the first policy package to the OTA management module.

[0215] Step S805, when the first policy package indicates to execute the upgrade operation of the first component, the OTA management module sends an upgrade instruction and the first policy package to the OTA upgrade module deployed on the first component.

[0216] Step S806, in the case of receiving the upgrade instruction, the OTA upgrade module obtains the information of the second component associated with the first component according to the identifier of the second component in the first policy package.

[0217] The information of the second component obtained in this step may include one or more of software information, firmware information, and hardware information.

[0218] In one example, the OTA upgrade module may send a second request to the OTA management module, where the second request is used to obtain one or more of the software information, firmware information, and hardware information of the second component, and the second request includes the identifiers of one or more second components. After receiving the second request, the OTA management module may, according to the identifiers of the second components included in the second request, obtain the software information, firmware information, and hardware information of the corresponding second components through the corresponding OTA upgrade module. Then, the OTA management module may send the obtained software information, firmware information, and hardware information to the OTA upgrade module deployed on the first component. In a possible implementation, the OTA management module may, in step S801, in addition to collecting the software information and firmware information of each component, also collect the hardware information of each component. In this way, after receiving the second request, the OTA management module may search for the software information, firmware information, and hardware information of the second component locally, without having to interact with the OTA upgrade module deployed on the second component, which can save time.

[0219] Step S807, the OTA upgrade module determines whether the second component meets the first condition according to the obtained information of the second component.

[0220] In the case where the second component associated with the first component meets the first condition, it indicates that the first component has the condition for upgrading, and the first component can be upgraded. At this time, step S808 can be executed.

[0221] Step S808, the OTA upgrade module upgrades the first component.

[0222] In the case where the software information and / or firmware information in the information of the second component does not meet the first condition, it indicates that the upgrade of the first component can be achieved only after the second component is upgraded. At this time, steps S809 to S814 can be executed.

[0223] Step S809, the OTA upgrade module sends a first request to the OTA management module, where the first request is used to request the upgrade of the second component.

[0224] Step S810, the OTA management module sends the first request to the OTA server.

[0225] Steps S809 and S810 can refer to step S709 and will not be elaborated here.

[0226] Step S811, in response to the first request, the OTA server returns the upgrade package of the second component and the second policy package corresponding to the second component to the OTA management module.

[0227] Step S811 can refer to step S710 and will not be elaborated here.

[0228] Step S812, when the second policy package instructs to perform the upgrade operation of the second component, the OTA management module upgrades the second component whose software information and / or firmware information does not meet the first condition by using the upgrade package of the second component, so that the second component meets the first condition.

[0229] Step S813, the OTA management module sends a message indicating that the upgrade of the second component is completed to the OTA upgrade module deployed in the first component.

[0230] Step S814, when the OTA upgrade module receives the message indicating that the upgrade of the second component is completed, it upgrades the first component.

[0231] Step S812 and Step S813 can refer to Step S807 and Step S808, which will not be elaborated here.

[0232] In the case where the hardware information in the information of the second component does not meet the first condition, it indicates that the hardware needs to be replaced to implement the functions of the upgraded first component. At this time, Step S815 and Step S816 can be executed.

[0233] Step S815, the OTA upgrade module sends a message indicating that the upgrade fails to the OTA management module.

[0234] Step S815 can refer to Step S614, which will not be elaborated here.

[0235] Step S816, after receiving the message indicating that the upgrade fails, the OTA management module notifies the user.

[0236] Step S816 can refer to Step S615, which will not be elaborated here.

[0237] The OTA-based upgrade method provided by the embodiments of the present application checks whether the second component associated with the first component meets the first condition when upgrading the software of the first component, so as to ensure the successful installation and activation of the upgrade package of the first component, reduce the upgrade error rate, and improve the user experience.

[0238] At the same time, the OTA upgrade module performs the check on whether the second component meets the first condition, which can reduce the workload of the OTA server and the workload of the OTA management module, and is beneficial to the synchronous upgrade of multiple components in the vehicle, especially beneficial to the vehicle-wide upgrade.

[0239] It should be noted that before the OTA server sends a policy package (such as the first policy package, the second policy package, etc.) or an upgrade package (such as the upgrade package of the first component, the upgrade package of the second component, etc.) to the OTA management module, it is necessary to sign the policy package and the upgrade package. After receiving the signed policy package or upgrade package, the OTA management module first verifies the signature of the policy package or upgrade package, and after the signature verification passes, it performs subsequent processing. Similarly, before the OTA management module sends a policy package or upgrade package to the OTA upgrade module, it is necessary to sign the policy package and the upgrade package. After receiving the signed policy package or upgrade package, the OTA upgrade module can first verify the signature of the policy package or upgrade package, and then perform subsequent processing after the signature verification passes. In this way, data security can be improved and the possibility of upgrade errors can be reduced.

[0240] Figure 9 FIG. shows a schematic structural diagram of an OTA-based upgrade device according to an embodiment of the present application. The device 90 can be disposed in any one of an OTA server, an OTA management module, and an OTA upgrade module. As Figure 9 shown, the device 90 may include:

[0241] An acquisition module 91, configured to acquire information of a second component associated with a first component; a determination module 92, configured to determine whether the second component meets a first condition according to the information of the second component acquired by the acquisition module 91, where the first condition is a condition that the second component needs to meet when upgrading the first component; a first upgrade module 93, configured to upgrade the first component through OTA when the determination module 92 determines that the second component meets the first condition.

[0242] In a possible implementation manner, the first condition is that when upgrading the first component, the information of the second component meets the matching range of the information of the second component required when upgrading the first component.

[0243] In a possible implementation manner, the information of the second component is at least one of hardware information, software information, and firmware information.

[0244] In a possible implementation manner, the device 90 further includes:

[0245] A second upgrade module, configured to upgrade the second component to make the second component meet the first condition when the software information and / or firmware information in the information of the second component does not meet the first condition.

[0246] In a possible implementation manner, the device 90 further includes:

[0247] A notification module, configured to notify that the vehicle-end upgrade fails when the hardware information in the information of the second component does not meet the first condition.

[0248] In an embodiment of the present application, when upgrading a first component, the information of a second component associated with the first component is checked; when the information of the second component meets the matching range of the information of the second component required for upgrading the first component, the first component is upgraded, thereby reducing the possibility of failure in upgrading the first component and problems such as partial function unavailability and error proneness after upgrading the first component, improving the reliability of OTA upgrade, and enhancing the user experience.

[0249] An embodiment of the present application provides an electronic device, including: a processor and a memory for storing processor-executable instructions; wherein, the processor is configured to implement the above method when executing the instructions.

[0250] An embodiment of the present application provides a computer program product, including computer-readable code, or a non-volatile computer-readable storage medium carrying the computer-readable code. When the computer-readable code runs in the processor of an electronic device, the processor in the electronic device executes the above method.

[0251] An embodiment of the present application provides a software upgrade device, including a memory and a processor. The memory stores computer program instructions, and the processor runs the computer program instructions to execute the above method.

[0252] In a first possible implementation manner of the software upgrade device, the device further includes a transceiver, configured to receive a policy packet, an upgrade packet, an upgrade failure message, or the information of the second component, or to send at least one of an upgrade instruction, an upgrade failure notification, etc.

[0253] The above software upgrade device can be applied to terminal devices in forms including but not limited to intelligent connected vehicles, robots, and smart homes. When applied to an intelligent connected vehicle, the software upgrade device can be the intelligent connected vehicle itself, or a component of the intelligent connected vehicle, such as a central gateway, a vehicle-to-internet vehicle-side communication terminal (Telematics BOX, T-box), a human-machine interaction controller (Human-Machine Interaction, HMI), a mobile data center (Mobile Data Controller, MDC), an advanced driving assistance system (Advanced Driving Assistant System, ADAS), or an electronic control unit (Electronic Control Unit, ECU), or a sub-device within the above components, or an independent device within the intelligent connected vehicle other than the above components.

[0254] An embodiment of the present application provides a software upgrade device, including a memory and a processor. The memory stores computer program instructions, and the processor runs the computer program instructions to execute the above method.

[0255] In a first possible implementation manner of the software upgrade device, the device further includes a transceiver, which is used to receive information of a second component, or is used to send at least one of an upgrade package, a policy package, an upgrade failure message, etc.

[0256] The above software upgrade device can be applied to the network side, for example, existing in the form of a server on the network side.

[0257] An embodiment of the present application provides a terminal software upgrade system, including the software upgrade device applicable to terminal devices and the software upgrade device applicable to the network side as described above.

[0258] An embodiment of the present application provides a computer-readable storage medium, including computer program instructions. When the computer instructions are run by a processor, the software upgrade device is enabled to execute the above method.

[0259] An embodiment of the present application provides an electronic device. The electronic device includes a processor configured to support the electronic device to execute the corresponding functions in the above method. The electronic device may further include a memory for coupling with the processor, which stores necessary program instructions and data of the electronic device. The electronic device may further include a communication interface for the electronic device to communicate with other devices or communication networks.

[0260] An embodiment of the present application provides a chip system. The chip system includes a processor for an electronic device or a server to implement the functions involved in the above method. For example, to receive or process the data and / or information involved in the above method. In a possible design, the chip system further includes a memory for storing necessary program instructions and data of the electronic device or the server. The chip system may be composed of chips or may include chips and other discrete devices.

[0261] In an embodiment of the present application, a computer-readable storage medium may be a tangible device that can hold and store instructions used by an instruction execution device. The computer-readable storage medium may be, for example, (but is not limited to) an electrical storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. More specific examples (non-exhaustive list) of the computer-readable storage medium include: a portable computer disk, a hard disk, a random access memory (RAM), a read only memory (ROM), an electrically programmable read-only memory (EPROM or flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disc (DVD), a memory stick, a floppy disk, a mechanical encoding device, such as a punched card or raised structures in grooves storing instructions thereon, and any suitable combination of the foregoing.

[0262] The computer-readable program instructions or code described herein may be downloaded from the computer-readable storage medium to various computing / processing devices, or downloaded to an external computer or external storage device through a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network may include a copper transmission cable, an optical fiber transmission, a wireless transmission, a router, a firewall, a switch, a gateway computer, and / or an edge server. A network adapter or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in the computer-readable storage medium in each computing / processing device.

[0263] The computer program instructions for performing the operations of the present application may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine - related instructions, microcode, firmware instructions, state - setting data, or source code or object code written in any combination of one or more programming languages, including object - oriented programming languages such as Smalltalk, C++, etc., and conventional procedural programming languages such as the "C" language or similar programming languages. The computer - readable program instructions may be executed entirely on the user's computer, partially on the user's computer, executed as a stand - alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., by using an Internet service provider to connect through the Internet). In some embodiments, by using the state information of the computer - readable program instructions to customize an electronic circuit, such as a programmable logic circuit, a field - programmable gate array (FPGA), or a programmable logic array (PLA), the electronic circuit can execute the computer - readable program instructions to implement various aspects of the present application.

[0264] Aspects of the present application are described herein with reference to the flowcharts and / or block diagrams of methods, apparatuses (systems), and computer program products according to embodiments of the present application. It should be understood that each block of the flowcharts and / or block diagrams, and combinations of blocks in the flowcharts and / or block diagrams, can be implemented by computer - readable program instructions.

[0265] These computer - readable program instructions can be provided to a processor of a general - purpose computer, a special - purpose computer, or other programmable data - processing device, thereby producing a machine such that when these instructions are executed by the processor of the computer or other programmable data - processing device, a device is produced that implements the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer - readable program instructions can also be stored in a computer - readable storage medium, and these instructions cause the computer, programmable data - processing device, and / or other devices to work in a specific manner. Thus, the computer - readable medium storing the instructions includes a manufactured article that includes instructions for implementing various aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0266] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other devices to produce a computer-implemented process such that the instructions executed on the computer, other programmable data processing apparatus, or other devices implement the functions / acts specified in one or more boxes of the flowchart and / or block diagram.

[0267] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of apparatus, systems, methods, and computer program products according to various embodiments of the present application. In this regard, each box in the flowchart or block diagram may represent a module, a segment of a program, or a portion of an instruction, which contains one or more executable instructions for implementing the specified logical function. In some alternative implementations, the functions noted in the boxes may occur out of the order noted in the figures. For example, two consecutive boxes may in fact be executed substantially in parallel, or they may sometimes be executed in the reverse order, depending on the functions involved.

[0268] It should also be noted that each box of the block diagrams and / or flowcharts, and combinations of boxes in the block diagrams and / or flowcharts, can be implemented by hardware (e.g., circuits or ASICs (Application Specific Integrated Circuits)) that perform the corresponding functions or acts, or can be implemented by a combination of hardware and software, such as firmware.

[0269] Although the present invention has been described in conjunction with the various embodiments, those skilled in the art will understand and realize other variations of the disclosed embodiments by viewing the figures, the disclosure, and the appended claims. In the claims, the word "comprising" does not exclude other elements or steps, and the singular "a" or "an" does not exclude a plurality. A single processor or other unit may implement several functions recited in the claims. Certain measures are recited in mutually different dependent claims, but this does not mean that these measures cannot be combined to produce a favorable effect.

[0270] The embodiments of the present application have been described above. The above description is exemplary and not exhaustive, and is not limited to the disclosed embodiments. Many modifications and variations are obvious to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The selection of the terms used herein is intended to best explain the principles of the embodiments, practical applications, or improvements to the technology in the market, or to enable other ordinary skill in the art to understand the embodiments disclosed herein.

[0271] As described above, the above is only a specific embodiment of the present invention, but the protection scope of the present invention is not limited thereto. Any person skilled in the art within the technical scope disclosed by the present invention can easily think of changes or substitutions, which should be covered within the protection scope of the present invention. Therefore, the protection scope of the present invention should be subject to the protection scope of the claims.

Claims

1. An upgrade method based on Over-the-Air (OTA) technology, characterized in that, the upgrade method is applied to a software upgrade system, the software upgrade system includes an OTA server and a vehicle, the vehicle includes an OTA management module and an OTA upgrade module, and the method includes: the OTA server receives the information of each component in the vehicle collected by the OTA management module; the OTA server determines a first policy package corresponding to a first component according to the information of each component, the first policy package is used to indicate upgrading the first component, and the first policy package includes a first condition that a second component associated with the first component needs to meet when upgrading the first component; the OTA server sends the first policy package to the OTA management module; the OTA management module determines whether the second component meets the first condition according to the first condition in the first policy package; when the second component meets the first condition, the OTA management module sends an upgrade instruction to the OTA upgrade module, and the OTA upgrade module is deployed on the first component; after receiving the upgrade instruction, the OTA upgrade module upgrades the first component.

2. The method according to claim 1, characterized in that, the first policy package further includes a download address of the upgrade package for upgrading the first component; the method further includes: the OTA management module downloads the upgrade package of the first component according to the download address in the first policy package; the OTA upgrade module upgrades the first component, including: the OTA upgrade module upgrades the first component according to the upgrade package of the first component.

3. The method according to claim 1 or 2, characterized in that, the information of each component in the vehicle collected by the OTA management module includes: software information, firmware information and hardware information of each component in the vehicle.

4. The method according to claim 1 or 2, characterized in that, the first policy package further includes an upgrade condition, and the upgrade condition includes: the vehicle is not in any of the following states: emergency event handling state, engine is in working state, storage space is insufficient, remaining traffic is lower than a preset traffic threshold.

5. An upgrade method based on Over-the-Air (OTA) technology, characterized in that, the method is applied to a server, and the method includes: receiving the information of each component in the vehicle collected by the OTA management module; determining a first policy package corresponding to a first component according to the information of each component, the first policy package is used to indicate upgrading the first component, and the first policy package includes a first condition that a second component associated with the first component needs to meet when upgrading the first component; Send the first policy package to the OTA management module; the first policy package is used for the OTA management module to determine whether the second component meets the first condition according to the first condition in the first policy package; and when the second component meets the first condition, send an upgrade instruction to the OTA upgrade module deployed in the first component, and the upgrade instruction is used for the OTA upgrade module to upgrade the first component; Wherein, the OTA management module and the OTA upgrade module are included in the vehicle.

6. The method according to claim 5, characterized in that The first policy package further includes the upgrade package download address for upgrading the first component; the download address is used for the OTA management module to download the upgrade package of the first component, and the upgrade package of the first component is used for the OTA upgrade module to upgrade the first component.

7. The method according to claim 5 or 6, characterized in that The information of each component in the vehicle collected by the OTA management module includes: software information, firmware information and hardware information of each component in the vehicle.

8. The method according to claim 5 or 6, characterized in that The first policy package further includes upgrade conditions, and the upgrade conditions include: the vehicle is not in any of the following states: emergency event handling state, engine is in working state, storage space is insufficient, and remaining traffic is lower than a preset traffic threshold.

9. An upgrade method based on Over-the-Air (OTA) technology, characterized in that The method is applied to a vehicle, the vehicle includes an OTA management module and an OTA upgrade module, and the method includes: The information of each component in the vehicle collected by the OTA management module; The OTA management module sends the information of each component in the vehicle collected to the OTA server; the information of each component is used for the OTA server to determine the first policy package corresponding to the first component according to the information of each component, and send the first policy package to the OTA management module, and the first policy package is used to indicate upgrading the first component, and the first policy package includes the first condition that the second component associated with the first component needs to meet when upgrading the first component; The OTA management module determines whether the second component meets the first condition according to the first condition in the first policy package; When the second component meets the first condition, the OTA management module sends an upgrade instruction to the OTA upgrade module, and the OTA upgrade module is deployed in the first component; After receiving the upgrade instruction, the OTA upgrade module upgrades the first component.

10. The method according to claim 9, characterized in that The first policy package further includes the upgrade package download address for upgrading the first component; the method further includes: The OTA management module downloads the upgrade package of the first component according to the download address in the first policy package; The OTA upgrade module upgrades the first component, including: The OTA upgrade module upgrades the first component according to the upgrade package of the first component.

11. The method according to claim 9 or 10, characterized in that, the information of each component in the vehicle collected by the OTA management module includes: software information, firmware information and hardware information of each component in the vehicle.

12. The method according to claim 9 or 10, characterized in that, the first policy package further includes upgrade conditions, and the upgrade conditions include: the vehicle is not in any of the following states: emergency event handling state, engine is in working state, storage space is insufficient, remaining traffic is lower than a preset traffic threshold.

13. An OTA-based upgrade device, characterized in that, the device includes a unit for executing the method according to any one of claims 1 to 4, or the device includes a unit for executing the method according to any one of claims 5 to 8, or the device includes a unit for executing the method according to any one of claims 9 to 12.

14. A computer-readable storage medium, on which computer program instructions are stored, characterized in that, when the computer program instructions are executed by a processor, the method according to any one of claims 1 to 4 is implemented, or when the computer program instructions are executed by a processor, the method according to any one of claims 5 to 8 is implemented, or when the computer program instructions are executed by a processor, the method according to any one of claims 9 to 12 is implemented.

15. A computer program product, characterized in that, it includes computer-readable code, or a non-volatile computer-readable storage medium carrying the computer-readable code, and when the computer-readable code runs in a processor of an electronic device, the method according to any one of claims 1 to 4 is implemented, or when the computer-readable code runs in a processor of an electronic device, the method according to any one of claims 5 to 8 is implemented, or when the computer-readable code runs in a processor of an electronic device, the method according to any one of claims 9 to 12 is implemented.

Images