WO2022165711A1

WO2022165711A1 - Upgrading method and apparatus based on over-the-air (ota) technology

Info

Publication number: WO2022165711A1
Application number: PCT/CN2021/075287
Authority: WO
Inventors: 王勇
Original assignee: 华为技术有限公司
Priority date: 2021-02-04
Filing date: 2021-02-04
Publication date: 2022-08-11
Also published as: CN112913190A

Abstract

An upgrading method and apparatus based on an over-the-air (OTA) technology. The method comprises: obtaining information of a second component associated with a first component (S501); according to the information of the second component, determining whether the second component satisfies a first condition (S502), wherein the first condition is a condition that the second component needs to satisfy when the first component is upgraded; and when the second component satisfies the first condition, upgrading the first component by means of OTA (S503). The upgrading method and apparatus based on the OTA technology can improve the reliability of OTA upgrading and improve user experience.

Description

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

technical field

The present application relates to the field of communication technologies, and in particular, to an upgrade method and device based on the over-the-air download technology OTA.

Background technique

Over the Air technology (OTA) is a technology for downloading data through a wireless network. It has been widely used in network upgrades of smart TVs, mobile phones, tablet computers, set-top boxes and other devices. With the development of intelligent and connected vehicles, OTA online upgrade has become an important function of automobiles. Original equipment manufacturers (Original Equipment Manufacture, OEM) can upgrade the relevant software and firmware of automobiles through OTA, which is conducive to OEM manufacturers to reduce recall costs and quickly Respond to needs and improve user experience. However, the use of some software packages requires dependencies on related software or hardware to ensure proper installation and use of the software packages.

Therefore, there is an urgent need to solve the problem of upgrade failure caused by the mismatch of related software or hardware, so as to improve the reliability of OTA upgrade.

SUMMARY OF THE INVENTION

In view of this, an upgrade method and device based on the over-the-air download technology OTA are proposed, which can solve the problem of upgrade failure caused by the mismatch of related software or hardware, thereby improving the reliability of OTA upgrade.

In a first aspect, an embodiment of the present application provides an OTA-based upgrade method, the method includes: acquiring information of a second component associated with a first component; determining the second component according to the information of the second component Whether the component satisfies the first condition, the first condition is the condition that the second component needs to meet when the first component is upgraded; if the second component satisfies the first condition, the OTA upgrades the first component.

In this embodiment of the present application, when the first component is upgraded, the information of the second component associated with the first component is checked; when the information of the second component satisfies the matching of the information of the second component required when the first component is upgraded When the first part is in the range, the first part is upgraded, thereby reducing the possibility of the failure of the first part to be upgraded, and the possibility of some functions being unavailable and error-prone after the first part is upgraded, which improves the reliability of the OTA upgrade and improves the user experience.

According to the first aspect, in a possible implementation manner, the first condition is that when the first component is upgraded, the information of the second component satisfies the second requirement required when the first component is upgraded. The matching range of the part's information. In this way, the flexibility and accuracy of the first condition can be improved.

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

According to the first aspect, in a first possible implementation manner, the method further includes: if the software information and/or firmware information in the information of the second component does not meet the first condition, then The second part is upgraded such that the second part satisfies the first condition.

In this way, by automatically upgrading the second part to realize the upgrade of the first part, the upgrade of the first part based on OTA can be completed without the user's perception, which is beneficial to improve the user experience.

According to an aspect, in a possible implementation manner, in a fourth possible implementation manner of the OTA-based upgrade method, the method further includes:

In the case that the hardware information in the information of the second component does not satisfy the first condition, the vehicle end is notified that the upgrade fails. In this way, it is convenient for the user to know the reason for the failure of the upgrade, and it is convenient for the user to replace the hardware.

In a second aspect, an embodiment of the present application provides an OTA-based upgrade device, the device comprising:

an acquisition module for acquiring the information of the second component associated with the first component;

a determining module, configured to determine whether the second part satisfies a first condition according to the information of the second part acquired by the acquiring module, and the first condition is that when the first part is upgraded, the second part needs to satisfy The first upgrade module is configured to upgrade the first component through the OTA when the determining module determines that the second component satisfies the first condition.

According to the second aspect, in a possible implementation manner, the first condition is that when the first component is upgraded, the information of the second component satisfies the second requirement when the first component is upgraded. The matching range of the part's information.

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

According to the second aspect, in a possible implementation manner, the apparatus further includes:

A second upgrade module, configured to upgrade the second component so that the second component satisfies the first condition if the software information and/or firmware information in the information of the second component does not satisfy the first condition the first condition.

According to the second aspect, or any one possible implementation manner of the above second aspect, in a fourth possible implementation manner of the OTA-based upgrading apparatus, the apparatus further includes:

The notification module is configured to notify the vehicle-end upgrade failure when the hardware information in the information of the second component does not meet the first condition.

In a third aspect, embodiments of the present application provide an electronic device, which can execute the first aspect or one or more of the OTA-based upgrade methods in multiple possible implementations of the first aspect.

In a fourth aspect, embodiments of the present application provide a computer program product, comprising computer-readable codes, or a non-volatile computer-readable storage medium carrying computer-readable codes, when the computer-readable codes are stored in an electronic When running in the device, the processor in the electronic device executes the first aspect or one or more of the OTA-based upgrade methods in the multiple possible implementation manners of the first aspect.

In a fifth aspect, the present application provides a software upgrade device, comprising a memory and a processor, the memory stores computer program instructions, and the processor executes the computer program instructions to execute the first aspect or any one of the above first aspects an implementation of the operation.

According to the fifth aspect, in a first possible implementation manner of the software upgrade apparatus, the apparatus further includes a transceiver, configured to receive a policy package, an upgrade package, an upgrade failure message or information of the second component, or use for sending at least one of upgrade instructions, upgrade failure notifications, etc.

The above fifth aspect, or the software upgrade apparatus described in any implementation manner of the fifth aspect, can be applied to terminal devices in the form of, but not limited to, intelligent networked vehicles, robots, and smart homes. When applied to an ICV, the software upgrade device may be the ICV itself, or a component of the ICV, such as a central gateway, a telematics BOX, T-box. , Human-Machine Interaction (HMI), Mobile Data Controller (MDC), Advanced Driving Assistant System (ADAS) or Electronic Control Unit (ECU), Or it is a sub-device in the above-mentioned components, or it can be an independent device in the intelligent networked vehicle in addition to the above-mentioned components.

In a sixth aspect, the present application provides a software upgrade device, comprising a memory and a processor, the memory stores computer program instructions, and the processor executes the computer program instructions to execute the first aspect or any one of the first aspects Implementation of the operation.

According to the sixth aspect, in a first possible implementation manner of the software upgrade apparatus, the apparatus further includes a transceiver for receiving information of the second component, or for sending an upgrade package, a policy package, an upgrade failure at least one of messages, etc.

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

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

In an eighth aspect, the present application provides a computer-readable storage medium, comprising computer instructions, which, when the computer instructions are executed by a processor, cause the software upgrade apparatus to execute the first aspect or any one of the above first aspects method of implementation.

In a ninth aspect, the present application provides an electronic device, the electronic device includes a processor, and the processor is configured to support the electronic device to perform corresponding functions in the method provided in the first aspect. The electronic device may also include a memory for coupling with the processor that holds program instructions and data necessary for the electronic device. The electronic device may also include a communication interface for the electronic device to communicate with other devices or a communication network.

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

These and other aspects of the present application will be more clearly understood in the following description of the embodiment(s).

Description of drawings

FIG. 1 shows a schematic diagram of a network architecture provided by an embodiment of the present application;

FIG. 2 shows a schematic diagram of a network architecture provided by an embodiment of the present application;

3 shows a schematic structural diagram of an electronic device for deploying an OTA server;

Fig. 4 shows the structural schematic diagram of Tbox;

Fig. 5a provides a kind of schematic flow chart of software upgrade;

Figure 5b shows a flowchart of an OTA-based upgrade method according to an embodiment of the present application;

FIG. 6 shows an interaction flowchart of an OTA-based upgrade method according to an embodiment of the present application;

FIG. 7 shows an interaction flowchart of an OTA-based upgrade method according to an embodiment of the present application;

FIG. 8 shows an interaction flowchart of an OTA-based upgrade method according to an embodiment of the present application;

FIG. 9 shows a schematic structural diagram of an OTA-based upgrade apparatus according to an embodiment of the present application.

Detailed ways

Various exemplary embodiments, features and aspects of the present application will be described in detail below with reference to the accompanying drawings. The same reference numbers in the figures denote elements that have the same or similar functions. While various aspects of the embodiments are shown in the drawings, the drawings are not necessarily drawn to scale unless otherwise indicated.

The word "exemplary" is used exclusively herein to mean "serving as an example, embodiment, or illustration." Any embodiment described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments. Hereinafter, the terms "first" and "second" are only used for descriptive purposes, and should not be construed as implying or implying relative importance or implying the number of indicated technical features. Thus, a feature defined as "first" or "second" may expressly or implicitly include one or more of that feature. In the description of the embodiments of the present application, unless otherwise specified, "plurality" means two or more.

In addition, in order to better illustrate the present application, numerous specific details are given in the following detailed description. It should be understood by those skilled in the art that the present application may be practiced without certain specific details. In some instances, methods, means, components and circuits well known to those skilled in the art have not been described in detail so as not to obscure the subject matter of the present application.

FIG. 1 shows a schematic diagram of a network architecture provided by an embodiment of the present application. As shown in Figure 1, the network architecture may include an Over the Air technology (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 (eg, 2G/3G/4G/5G network), and can also communicate with the OTA server through a wireless local area network (WLAN). This embodiment of the present application does not limit the wireless communication link.

As shown in Figure 1, the vehicle at least includes a gateway (GateWay, GW), a mobile data center (Mobile Data Center, MDC), a human-machine interaction system (Human-Machine Interaction, HMI), a telematics control unit (Telematics Control Unit, TCU), automotive box (Telematics box, Tbox), electronic control unit (Electronic Control Unit, ECU) and other components.

Among them, the GW is the core component in the electronic and electrical architecture of the vehicle. As the data interaction hub of the vehicle network, GW can integrate the Controller Area Network (CAN), Local Interconnect Network (LIN), multimedia Network data such as software upgrade (Media Oriented System Transport, MOST) networks are routed in different networks. MDC is an intelligent in-vehicle computing platform for vehicles, and MDC can be used to realize automatic driving functions of vehicles. HMI is the infotainment system of the vehicle. TCU and Tbox are mainly used to communicate with external devices of the vehicle (such as mobile phones, background systems, etc.). ECU is a vehicle-specific microcomputer controller. ECUs include but are not limited to Vehicle Integrated/Intergration Unit (VIU), Cockpit Domain Controller (CDC), Vehicle Domain Controller (VDC), etc. In this embodiment of the present application, the first component to be upgraded includes but is not limited to the aforementioned GW, MDC, HMI, TCU, Tbox, and ECU, and the first component to be upgraded may include the aforementioned GW, MDC, HMI, TCU, Tbox, and ECU one or more of the.

Vehicle OTA upgrade usually involves the upgrade of multiple components in the vehicle, so an OTA management module (which can be called an OTA Master module) is required to coordinate the upgrade of these multiple components. The OTA management module can run on the GW, Tbox and other components of the vehicle, and coordinate the OTA upgrade modules (which can be called OTA Slave modules) of other components to complete the vehicle upgrade together.

FIG. 2 shows a schematic diagram of a network architecture provided by an embodiment of the present application. As shown in Figure 2, the OTA management module is deployed in the GW of the vehicle, and the OTA upgrade module is deployed in other parts of the vehicle. Among them, the OTA management module can coordinate the OTA upgrade modules deployed by each component to jointly complete the OTA upgrade of the entire vehicle. 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, and so on. Based on the configuration information, a secure channel can be established between the OTA server and the OTA management module, such as Hyper Text Transfer Protocol over SecureSocket layer (HTTPS), Transport Layer Security (TLS) or data packets Transport layer security protocol (Datagram Transport Layer Security, DTLS) and other security channels, so as to securely transmit information between the OTA server and the OTA management module, for example, securely transmit the policy packages, upgrade packages, The information of the second component and the first condition, etc.

In this embodiment of the present application, the OTA server may be deployed on an electronic device with a wireless communication function and a storage function, or may be deployed on a virtual machine (Virtual Machine, VM) or a container on the cloud, where the cloud may be multiple electronic devices A cluster of devices. FIG. 3 shows a schematic structural diagram of an electronic device for deploying an OTA server.

As shown in FIG. 3 , the electronic device may include at least one processor 301 , a memory 302 , an input and output device 303 and a bus 304 . Below in conjunction with Fig. 3, each constituent part of the electronic device is introduced in detail:

The processor 301 is the control center of the electronic device, and may be a processor or a general term for multiple processing elements. For example, the processor 301 is a CPU, and may also be a specific integrated circuit (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 microprocessors A digital signal processor (DSP), or one or more field programmable gate arrays (Field Programmable Gate Array, FPGA).

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 .

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.

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

Memory 302 may be Read-Only Memory (ROM) or other types of static storage devices that can store static information and instructions, Random Access Memory (RAM), or other types of information and instructions that can be stored It can also be an electrically erasable programmable read-only memory (Electrically Erasable Programmable Read-Only Memory, EEPROM), a compact disc read-only memory (CD-ROM) or other optical disk storage, optical disk 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 capable of carrying or storing desired program code in the form of instructions or data structures and capable of being executed by a computer Access any other medium without limitation. The memory 302 can exist independently and is connected to the processor 301 through the bus 304 . The memory 302 may also be integrated with the processor 301 . In this embodiment of the present application, the memory may be used for a policy package, an upgrade package, and the like.

Input and output devices 303 for communicating with other devices or communication networks. For example, it is used to communicate with communication networks such as Ethernet, Radio access network (RAN), Wireless Local Area Networks (WLAN). The input-output device 303 may include all or part of a baseband processor, and may optionally include a radio frequency (Radio Frequency, RF) processor. The RF processor is used for transmitting and receiving RF signals, and the baseband processor is used for processing the baseband signal converted by the RF signal or the baseband signal to be converted into the RF signal.

In a specific implementation, as an embodiment, the input-output device 303 may include a transmitter and a receiver. The transmitter is used to send signals to other devices or communication networks, and the receivers are used to receive signals sent by other devices or communication networks. The transmitter and receiver can exist independently or can be integrated. In this embodiment of the present application, the input and output device may be used to send and receive: a policy package, an upgrade package, the information of the second component, the first condition, and the like.

The bus 304 can be an industry standard architecture (Industry Standard Architecture, ISA) bus, a peripheral device interconnect (Peripheral Component Interconnect, PCI) bus, or an extended industry standard architecture (Extended Industry Standard Architecture, EISA) bus and the like. The bus can be divided into address bus, data bus, control bus and so on. For ease of presentation, only one thick line is used in FIG. 3, but it does not mean that there is only one bus or one type of bus.

The device structure shown in FIG. 3 does not constitute a limitation to the electronic device, and may include more or less components than shown, or combine some components, or arrange different components.

In this embodiment of the present application, the Tbox component can be used to deploy both the OTA management module and the OTA upgrade module. The following takes Tbox as an example to illustrate the structure of the vehicle components. FIG. 4 shows a schematic diagram of the structure of the Tbox.

As shown in FIG. 4 , the Tbox 40 includes an application layer microprocessor unit (MicroProcessor Unit, MPU) 41 and a microcontroller unit (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. Communication between the MPU 41 and the MCU 42 is performed through a General Purpose Input Output (GPIO) interface and a Serial Peripheral Interface (SPI).

The MPU 41 includes a host computer 411 and a wireless communication module 412. The host computer 411 corresponds to the chip function layer, and the wireless communication module 412 corresponds to the chip wireless communication layer.

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

Memory may also be provided in the microprocessor for storing instructions and data. In some embodiments, the memory in the microprocessor is a cache memory. This memory can hold instructions or data that have just been used or cycled by the microprocessor. If the microprocessor needs to use the instruction or data again, it can be called directly from the memory. Repeated access is avoided, and the waiting time of the microprocessor is reduced, thereby improving the efficiency of the system.

The microprocessor may run the OTA-based upgrade method provided by the embodiment of the present application, so as to reduce the upgrade error rate and improve the user experience. The microprocessor may include different devices. For example, when the CPU and the GPU are integrated, the CPU and the GPU may cooperate to execute the OTA-based upgrade method provided by the embodiments of the present application. For example, in the OTA-based upgrade method, some algorithms are executed by the CPU, and another part of the algorithms Executed by GPU for faster processing efficiency.

After the microprocessor runs the OTA-based upgrade method provided by the embodiment 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 and the policy package according to the OTA-based upgrade method provided by the embodiment of the present application Wait.

MPU 41 may also include internal memory (not shown). Internal memory may be used to store computer executable program code, which includes instructions. The microprocessor executes various functional applications and data processing of the MPU 41 by executing the instructions stored in the internal memory. The internal memory may include a stored program area and a stored data area. Among them, the stored program area can store the operating system, the code of the application program, and the like.

The internal memory may 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 configured to be executed by the above-mentioned one or more microprocessors, and the one or more computer programs include instructions that can be used to execute the program according to the embodiments of the present application. The individual steps of the OTA-based upgrade method.

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

The modem processor may include a modulator and a demodulator. Wherein, the modulator is used to modulate the low frequency baseband signal to be sent into a medium and high frequency signal. The demodulator is used to demodulate the received electromagnetic wave signal into a low frequency baseband signal. Then the demodulator transmits the demodulated low-frequency baseband signal to the baseband processor for processing. The low frequency baseband signal is processed by the baseband processor and passed to the application processor. The application processor outputs sound signals through audio devices (not limited to speakers, microphones, etc.), or displays images or videos through a display screen. In some embodiments, the modem processor may be a stand-alone device. In other embodiments, the modem processor may be independent of the microprocessor, and be provided in the same device as the wireless communication module 412 or other functional modules.

The MCU 42 can be connected to the vehicle through the Ethernet, and can also be connected to other components in the vehicle body through the CAN network, such as sensors arranged on the vehicle body.

It can be understood that the structures illustrated in the embodiments of the present application do not constitute a specific limitation on the Tbox. In other embodiments of the present application, the Tbox may include more or less components than shown, or some components are combined, or some components are split, or different components are arranged. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

Figure 5a provides a schematic flowchart of a software upgrade. This flow can be applied to the architecture shown in Figure 2. As shown in Figure 5a, the software upgrade process includes: 1. The OTA server signs the upgrade package; 2. The OTA server issues the signed upgrade package through the 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 is passed, the OTA management module disassembles and distributes the upgrade package to the OTA upgrade module of the corresponding component; 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.

In implementation, when the OTA server issues a signed upgrade package to the OTA management module, it also issues a policy package to the OTA management module, where the policy package indicates the software upgrade sequence of each component in the vehicle. When it is determined to perform an upgrade operation of a certain component according to the policy package, for example, when it is determined to perform an upgrade operation of 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 an upgrade completion message to the OTA management module, so that the OTA management module can determine the upgrade progress. In an example, after the OTA upgrade module receives the message that the first component is upgraded, it can determine A software upgrade operation of another component is performed. In yet another example, after the OTA receives a message that the upgrade of the first component is completed, it may determine that all the upgrades are completed.

However, when the first part is upgraded, it does not consider the need for the related parts to be upgraded. In practice, the use of upgrade packages for some components requires the software, hardware or firmware of other components to meet certain conditions. For example, new automatic driving functions may require related sensors to be used in specific software and hardware versions. If the relevant sensor is not in a specific software version and/or hardware version, even if the new automatic driving function is upgraded, the function may not be available, for example, it may prompt that the sensor is not detected, or because the sensor has not been received. Detecting data and reporting errors, etc.

Therefore, the embodiments of the present application provide an OTA-based upgrade method, which can provide guarantee for component upgrade, improve the probability of successful component upgrade, and thus improve user experience.

The OTA-based upgrade method provided in the embodiment of the present application can realize both the upgrade of the entire vehicle (that is, the upgrade of multiple components in the vehicle based on OTA), and the software upgrade of a single component in the vehicle (that is, the upgrade of the vehicle based on OTA). to upgrade any of the components). When upgrading the entire vehicle, each component to be upgraded can be upgraded separately according to a certain upgrade sequence.

The OTA-based upgrade method provided by the embodiment of the present application is described below by taking the first component as the component to be upgraded as an example. Wherein, the first component may be any component. The first component may be any one of multiple components that need to be upgraded in the whole vehicle upgrade, or may be a single upgraded component. For the whole vehicle upgrade, the upgrade method of other components that need to be upgraded is the same as the upgrade method of the first component, which is not repeated in the embodiment of the present application.

The OTA-based upgrade method provided in this embodiment of the present application may be applied to the architecture shown in FIG. 2 . The method may be performed by any one of the OTA server, the OTA management module, and the OTA upgrade module.

FIG. 5b shows a flowchart of an OTA-based upgrade method according to an embodiment of the present application. As shown in Figure 5b, the method may include:

Step S501, acquiring information of a second component associated with the first component.

In this embodiment of the present application, the first component may represent any component to be upgraded. The second component associated with the first component may represent a component that needs to meet certain conditions when upgrading the first component.

There may be one or more second components associated with the first component. The second component associated with the first component may include the first component, that is, the upgrade of the first component may require the first component itself to satisfy certain conditions. The second component associated with the first component may include other components other than the first component, that is, the software upgrade of the first component may require the other components other than the first component to satisfy certain conditions.

Step S502: Determine whether the second component satisfies the first condition according to the information of the second component.

In this embodiment of the present application, the condition that the second component needs to meet when the first component is upgraded may be referred to as the first condition. That is, when the second component satisfies the first condition, the first component can be upgraded, and when the second component does not satisfy the first condition, the first component cannot be upgraded.

In an implementation, it may be determined whether the second component satisfies the first condition according to the information of the second component. Wherein, the information of the second component is at least one item of hardware information, software information and firmware information. The hardware information may include a hardware version number and/or a hardware model; the software information may include a software version number; and the firmware information may include a firmware version number. Correspondingly, the first condition may be that when the first component is upgraded, the information of the second component satisfies the matching range of the information of the second component required when the first component is upgraded. That is to say, when the first part is upgraded, if the information of the second part satisfies the matching range of the information of the second part required for the upgrade of the first part, it indicates that the second part satisfies the first condition, and the matching The upgrade of the first component; if the information of the second component does not meet the matching range of the information of the second component required for the upgrade of the first component, it indicates that the second component does not meet the first condition, and the first component cannot be upgraded at this time. upgrade.

In this embodiment of the present application, the matching range of the information of the second component required when the first component is upgraded may be generated by an OTA server or a content delivery network (Content Delivery Network, CDN). In a possible implementation manner, the OTA server may determine the software version information of the first component after the upgrade according to the software version information of the first component before the upgrade; and generate the first component upgrade according to the software version information of the first component after the upgrade When the matching range of the information of the second part is required. Alternatively, the OTA server may obtain, from the CDN, the matching range of the information of the second component required for the upgrade of the first component according to the software version information of the first component after the upgrade. In implementation, the matching range of the information of the second component required when the first component is upgraded may be included in the first policy package for instructing the first component to be upgraded.

The matching range of the information of the second component required when the first component is upgraded 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 the first component is upgraded may involve the hardware information, software information and firmware information of the second component one or more of.

In a possible implementation manner, the matching range of the information of the second component required when the first component is upgraded may be the hardware information of the second component A. That is to say, when the first component is upgraded, the hardware information of the second component A needs to satisfy the hardware information of the second component A required when the first component is upgraded, so that the first component can be upgraded.

For example, when the first component is upgraded from software version 1.0 to software version 2.0, the required matching range of the information of the second component may 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 the first component is upgraded, it indicates that the second component A does not meet the first condition, and the upgrade of the first component cannot be implemented. If the hardware version of the second component is 3.0 or 4.0 when the first component is upgraded, it indicates that the second component A satisfies the first condition, and the first component can be upgraded. Assuming that the first component is upgraded from software version 1.0 to software version 2.0, the hardware version of the second component A is 3.0 and the hardware model is 1234 or 1235. When upgrading the first component, the first component can be upgraded only when the hardware version of the second component A is 3.0 and the hardware model is one of 1234 and 1235.

In a possible implementation manner, the matching range of the information of the second component required when the first component is upgraded may be the software information of the second component A. That is to say, when the first component is upgraded, the software information of the second component A needs to satisfy the software information of the second component A required when the first component is upgraded, so that the first component can be upgraded.

For example, assuming that 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 the version of the second component A is above 6.0, indicating that the software of the first component The version has been upgraded to 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 required matching range of the information of the second component can be : The software version of the second part 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 the first component is upgraded, it indicates that the second component A satisfies the first condition and the first component can be upgraded. 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 first component cannot be upgraded.

In a possible implementation manner, the matching range of the information of the second component required when the first component is upgraded may be the firmware information of the second component A. That is, when the first component is upgraded, the hardware information of the second component A needs to satisfy the firmware information of the second component A required for the first component to be upgraded, so that the first component can be upgraded.

For example, when the first component is upgraded from software version 1.0 to software version 2.0, the required matching range of the information of the second component may 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 the first component is upgraded, the upgrade of the first component cannot be implemented. For another example, when the first component is upgraded from software version 1.0 to software version 2.0, the required matching range of the information of the second component may be: the firmware version of the second component A is not 3.0.

In a possible implementation manner, the matching range of the information of the second component required when the first component is upgraded may be the hardware information and software information of the second component A. That is to say, when the first component is upgraded, the hardware information of the second component A needs to meet the hardware information of the second component A required when the first component is upgraded, and the software information of the second component A needs to meet the hardware information of the second component A when the first component is upgraded. Only the software information of the second component A is required to realize the upgrade of the first component.

For example, when the first component is upgraded from software version 1.0 to software version 2.0, the required matching range of the information of the second component may 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 more.

In a possible implementation manner, the matching range of the information of the second component required when the first component is upgraded may be the hardware information and firmware information of the second component A. That is to say, when the first component is upgraded, the hardware information of the second component A needs to meet the hardware information of the second component A required when the first component is upgraded, and the firmware information of the second component A needs to meet the hardware information of the second component A when the first component is upgraded. Only the firmware information of the second component A is required to realize the upgrade of the first component.

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

In a possible implementation manner, the matching range of the information of the second component required when the first component is upgraded may be the software information and firmware information of the second component A. That is to say, when the first component is upgraded, the software information of the second component A needs to meet the software information of the second component A required when the first component is upgraded, and the firmware information of the second component A needs to meet the software information of the second component A when the first component is upgraded. Only the firmware information of the second component A is required to realize the upgrade of the first component.

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

In a possible implementation manner, the matching range of the information of the second component required when the first component is upgraded may be the hardware information, software information and firmware information of the second component A. That is to say, when the first component is upgraded, the hardware information of the second component A needs to meet the hardware information of the second component A required when the first component is upgraded, and the software information of the second component A needs to meet the hardware information of the second component A when the first component is upgraded. The software information of the second component A is required, and the firmware information of the second component A needs to satisfy the firmware information of the second component A required when the first component is upgraded, so that the first component can be upgraded.

For example, when first upgrading from software version 1.0 to software version 2.0, the required matching range of the information of the second component may 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.

In a possible implementation manner, the matching range of the information of the second component required when the first component is upgraded may be the software information of the second component A and the hardware information of the second component B. That is to say, when the first component is upgraded, 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, and the hardware information of the second component B needs to meet the requirements for the upgrade of the first component. Only the hardware information of the second component B is required to realize the upgrade of the first component.

For example, when upgrading from software version 1.0 to software version 2.0 for the first time, the matching range of the information of the second component required may be: the software version of the second component A is 2.0 or above, and the hardware version of the second component B is is 3.0 or higher, and the hardware model of the second component B is any model except 1234.

In a possible implementation manner, the matching range of the information of the second component required when the first component is upgraded may be the firmware information and software information of the second component A, the hardware information of the second component B, and the second component C's software information, firmware information and hardware information. That is to say, when the first component is upgraded, the firmware information and software information of the second component A need to satisfy the firmware information and software information of the second component A required by the upgrade of the first component, respectively, and the hardware information of the second component B needs to be Satisfy the hardware information of the second component B required when the first component is upgraded, and the software information of the second component C needs to meet the software information of the second component C and the firmware information of the second component C required when the first component is upgraded It is necessary to satisfy the firmware information of the second component C required when the first component is upgraded, and the hardware information of the second component C to meet the hardware information of the second component C required when the first component is upgraded, in order to realize the upgrade of the first component .

For example, assuming that the first component is the MDC, when upgrading the automatic driving function for the MDC, the current software version of the MDC needs to be 2.0, the software version of the sensor 1 in the MDC needs to be 2.0, and the hardware model of the sensor 2 is XXXX. When the MDC is used as the first component, the second component associated with the first component includes the MDC, sensor 1 and sensor 2. The matching range of the information of the second component required when the first component is upgraded is: software information of the MDC, sensor 1 software information, and hardware information of sensor 2. When upgrading MDC, the software information of MDC satisfies that the software version of MDC is 2.0, the software information of sensor 1 satisfies that the software version of sensor 1 is 2.0, and the hardware information of sensor 2 satisfies that when the hardware model of sensor 2 is XXXX, It indicates that the second component associated with the MDC satisfies the first condition, and the MDC can be upgraded.

It can be understood that the above examples are only examples, and the first component may be any component of the vehicle, which is not limited in this embodiment of the present application.

Step S503, when the second component satisfies the first condition, upgrade the first component through OTA.

Optionally, when the second component satisfies the first condition, an upgrade package of the first component may be downloaded, installed and activated from an OTA server or CDN through OTA, so as to upgrade the first component.

It is considered that the information of the second component may be at least one of hardware information, software information and firmware information. Therefore, one or more of hardware information, software information and firmware information may be involved in the matching range of the information of the second component required when the first component is upgraded. 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.

In a possible implementation, if the software information and/or firmware information in the information of the second component does not meet the first condition, the second component may be upgraded so that the second component satisfies the first condition. a condition. After the first condition is met, the first component is upgraded.

In the first condition, the matching range of the information of the second component required when the first component is upgraded may include software information and/or firmware information. In the case that the software information and/or firmware information of the second component does not meet the above-mentioned first condition, the second component may be upgraded, so that the upgraded information of the second component satisfies the second component required when the first component is upgraded The matching range of the information, so that the upgraded second component satisfies the first condition. After that, the first part can be upgraded via OTA.

In this way, it can be ensured that when the first component is upgraded, the associated second component satisfies the first condition, thereby reducing the possibility of upgrade errors and improving user experience. At the same time, when the software information and/or firmware information in the information of the second component does not meet the first condition, the second component is upgraded first, and then the first component is upgraded, so that the probability of successful upgrade of the first component can be improved. Conducive to the upgrade of the first part.

It can be understood that, in this 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 upgrading the first component, the first component cannot be upgraded. After the second component is upgraded one or more times, if the second component still fails to meet the first condition, the vehicle end may be notified that the upgrade fails, so as to facilitate the user to conduct investigation.

In a possible implementation manner, in the case that the hardware information in the information of the second component does not meet the first condition, the on-board upgrade failure is notified.

In the first condition, the matching range of the information of the second component required when the first component is upgraded may include hardware information. If the hardware information of the second component does not meet the above-mentioned first condition, upgrading the software of the second component cannot make the second component meet the first condition, and the hardware of the second component needs to be replaced to make the second component meet the first condition. condition. Therefore, in the case that the hardware information in the information of the second component does not meet the first condition, the on-board upgrade failure can be notified, so as to facilitate the user to replace the hardware.

In this way, the possibility of an upgrade error can be reduced, and the user can be prompted for the reason why the upgrade cannot be performed, thereby improving the user experience.

Optionally, in the case that the software information and/or firmware information in the information of the second component does not meet the first condition, and the hardware information in the information of the second component does not meet the first condition, you can temporarily not upgrade the second component. Parts, and directly notify the vehicle end of the upgrade failure, which can save time and workload.

The method shown in FIG. 5b may be performed by any one of the OTA server, the OTA management module and the OTA upgrade module. In the case where the method shown in FIG. 5b is executed by the OTA server, the interaction flow between the OTA server, the OTA management module and the OTA upgrade module can be referred to in FIG. 6 . In the case where the method shown in FIG. 5b is executed by the OTA management module, the interaction flow between the OTA server, the OTA management module and the OTA upgrade module may refer to FIG. 7 . In the case where the method shown in FIG. 5b is performed by the OTA upgrade module, the interaction flow between the OTA server, the OTA management module and the OTA upgrade module can be referred to in FIG. 8 .

The process of executing the method shown in FIG. 5b by the OTA server will be described below with reference to FIG. 6 . FIG. 6 shows an interaction flowchart of an OTA-based upgrade method according to an embodiment of the present application. As shown in Figure 6, the OTA-based upgrade method includes:

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

The software information may include a software version number, the firmware information may include a firmware version number, and the hardware information may include a hardware model and/or a hardware version number. Components in the vehicle include, but are not limited to, the components shown in FIG. 2 . The OTA management module may be deployed in the GW (as shown in FIG. 2 ), or may be deployed in other components (not shown), for example, in the Tbox, which is not limited in this embodiment of the present application. In one example, the OTA management module may send a message to collect the information of the component to the OTA upgrade module deployed by each component. After each component is deployed, the OTA upgrade module can return one or more of the software information, firmware information and hardware information of the component to the OTA management module after receiving the message of collecting the information of the software and hardware components.

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

After the OTA management module confirms that each OTA upgrade module completes the information reporting, it can report the collected information of each component to the OTA server. In one example, the OTA management module may send the identities of the components, and the information associated with each identity, to the OTA server. The identifier of the component may be used to identify a unique component, and the identifier of the component may include the name of the component, the number of the component, or the address of the component, etc., which is not limited in this application.

In a possible implementation manner, the OTA management module may collect the information of each component in the vehicle and send it to the OTA server under the condition of establishing a wireless communication link with the OTA server or under the condition of receiving the indication of the reporting information sent by the OTA server. The OTA server reports the information of each component. The OTA management module can also periodically collect the information of various components in the vehicle, and when a wireless communication link is established with the OTA server or when receiving an indication of the reported information sent by the OTA server, the currently collected The information of each component is reported to the OTA server. In the embodiment of the present application, the timing of collecting the information of each component and reporting the information of each component by the OTA management module is not limited.

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

The first policy package may be used to represent a policy package corresponding to the first component. The first policy package may be used to instruct to upgrade the first component.

Optionally, the first policy package includes a first condition, that is, a condition that needs to be satisfied by the second component associated with the first component when the first component is upgraded. In implementation, the first policy package may include the identifier of the second component associated with the first component, and the first condition. In this way, the OTA server can 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 according to the identifier of the second component.

In application, the first policy package may further include upgrade conditions, upgrade types, upgrade order, user notification policy, upgrade package size, and upgrade package download address, and the like. The upgrade conditions may include: the vehicle is not in the following states: emergency handling state, the engine is in working state, the storage space is insufficient, the remaining flow rate is lower than a preset flow rate threshold, and the like. When the vehicle is in any of the above states, the downloading process of the upgrade package is prone to a situation such as a download endpoint, which in turn causes the download of the upgrade package to fail. Upgrade types can include: silent (upgrade without user notification), regular (upgrade with user consent), and mandatory (upgrade without user consent after notification). The upgrade sequence may indicate the chronological sequence of upgrades of different components. For example, when upgrading the automatic driving function for MDC, it is necessary to upgrade the sensors first (if the software versions of multiple sensors need to be upgraded, each sensor can be upgraded at the same time or in a certain chronological order), and then upgrade the MDC. The size of the upgrade package is generally from a few M to a dozen M. The upgrade package download address can point to an OTA server or a Content Delivery Network (CDN), that is, the upgrade package can be downloaded from an OTA server or a CDN server.

In implementation, the OTA server may determine the software version information of the first component after the upgrade according to the software version information of the first component before the upgrade, and obtain the upgrade of the first component from the software warehouse according to the software version information of the first component after the upgrade The download address of the package or the upgrade package of the first component. The OTA server may generate the first policy package according to 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-mentioned first policy package can also be generated by the software warehouse according to 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 can obtain the first policy package from the software warehouse. In this embodiment of the present application, the method for generating the first policy package is not limited.

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.

The first policy package may include the identification of one or more second components. Because through steps S601 and S602, the OTA server obtains the information of various components in the vehicle. Therefore, the OTA server can separately find information about each second component associated with the first component in the acquired information according to the identifier of each second component.

The information of the second component searched in this step may include one or more of software information, firmware information and hardware information. The content of the information to be specifically searched for may be determined according to the matching range indicated in the first condition. For example, 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. For another example, 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 be found out, and when it is subsequently determined whether the second component satisfies the first condition, the required information can be selected for matching.

Step S605, the OTA server determines whether the second component satisfies the first condition according to the found information of the second component.

The first condition is that when the first component is upgraded, the information of the second component satisfies the matching range of the information of the second component required when the first component is upgraded. It will be understood that there may be one or more second components associated with the first component. For each second part, there is a matching range of the information of the second part required when the first part is upgraded.

For each second component: through step S603, the OTA server can obtain the matching range (ie, the first condition) of the information of the second component required when the first component is upgraded, and through step S604, the OTA server can obtain the Information about the second part. Based on this, in this step, the OTA server may determine whether the second component satisfies the first condition according to the information of the second component. When the information of the second component satisfies the matching range of the information of the second component required when the first component is upgraded, it may be determined that the second component satisfies the first condition.

It can be understood that, when all the second components satisfy the first condition, it can be determined that the second components associated with the first component satisfy the first condition.

In the case that the second component associated with the first component satisfies the first condition, it indicates that the first component has the upgrade condition, the first component can be upgraded, and steps S606 to S608 can be performed at this time.

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

Step S607, 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 by the first component.

The upgrade instruction is used to instruct the OTA upgrade module to perform an upgrade operation, specifically installing and activating the upgrade package.

In one example, the first policy package includes an upgrade condition, an upgrade type, and an upgrade sequence, and 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 the OTA management module receives the first policy package and parses the first policy package, if it is determined that the current engine is not in a working state, the OTA management module may determine that an upgrade operation of the first component needs to be performed currently. At this time, the OTA management module may send an upgrade instruction to the OTA upgrade module deployed by the first component.

Step S608, after receiving the upgrade instruction, the OTA upgrade module upgrades the first component.

In a possible implementation manner, the upgrade instruction sent in step S607 may include an upgrade package of the first component. In step S608, after receiving the upgrade instruction, the OTA upgrade module may obtain the upgrade package of the first component from the upgrade instruction, and 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 delivered by the OTA server to the OTA management module when the first policy package is delivered in step 606, or after the OTA management module receives the first policy package, It is downloaded according to the download address in the first policy package (from the OTA server or CDN).

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 may obtain the download address of the upgrade package of the first component from the upgrade instruction, and download the upgrade package of the first component according to the download address (from the OTA server or CDN). , install and activate the upgrade package for the first part to upgrade the first part.

The embodiment of the present application implements the upgrade of the first component through OTA, and the embodiment of the present application does not limit the manner of acquiring the upgrade package of the first component.

The information of the second component may be at least one of hardware information, software information and firmware information. The fact that the second component does not satisfy the first condition may be caused by the fact that 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 required for upgrading the first component, or it may be caused by the The hardware information of the second component does not meet the hardware information of the second component required for upgrading the first component. It may also be caused by the software information and/or firmware information of the second component, as well as the hardware information, which do not meet the requirements for upgrading the first component. When required, the software information and/or firmware information of the second component, as well as the hardware information. In the case where the software information and/or firmware information is not satisfied, the software information and/or firmware information of the second component can be updated to satisfy the software information and/or firmware of the second component required for upgrading the first component by upgrading the second component. information, so that the second component satisfies the first condition. When the hardware information is not satisfied, the first component needs to be replaced by replacing the hardware. The interaction process in the above two cases is described below.

If 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 be upgraded only after the second component is upgraded. In this case, steps S609 to S613 may be performed.

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.

Here, for any second component associated with the first component: the matching range of the information of the second component required when the first component is upgraded includes software information and/or firmware information, and when the first component is upgraded, the second component If the software information and/or firmware information of the component does not satisfy the software information and/or firmware information of the second component required for the upgrade of the first component indicated in the first condition, it indicates that the software information of the second component does not Satisfying the first condition, the second component may be determined as a second component whose software information and/or firmware information does not satisfy the first condition.

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 satisfies the first condition, and then the first component needs to be upgraded. The associated second component satisfies the first condition. Therefore, the OTA server may obtain an upgrade package of the second component whose software information and/or firmware information does not satisfy the first condition, so as to upgrade the second component.

The second policy package may be used to represent the policy package corresponding to the second component. The second policy package may be used to instruct to upgrade the second component. The second policy package includes an upgrade sequence between the second components, and the OTA management module may instruct different second components to upgrade according to the upgrade sequence.

In a possible implementation manner, the second policy package may further include an identifier of a third component associated with the second component, and a second condition. The third component associated with the second component may represent a component that needs to meet certain conditions when upgrading the second component. In this embodiment of the present application, the condition that the third component needs to meet when the second component is upgraded may be referred to as the second condition. That is, when the third component satisfies the second condition, the second component can be upgraded, and when the third component does not meet the second condition, the second component cannot be upgraded. The second condition may be that when the second component is upgraded, the information of the third component satisfies the matching range of the information of the third component required when the second component is upgraded. For the second condition, reference may be made to the first condition, which will not be repeated here.

In a possible implementation manner, the second policy package may further include upgrade conditions, upgrade type, upgrade sequence, user notification policy, upgrade package size, and upgrade package download address, and the like. For the second policy package, reference may be made to the first policy package, which will not be repeated here.

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.

Step S611, when the second policy package instructs to perform 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 software information and/or firmware information do not meet the first condition. The second component satisfies the first condition.

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

Step S612, when the first policy package instructs to perform an upgrade operation of the first component, the OTA management module sends an upgrade instruction to the OTA upgrade module deployed by the first component.

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

For steps S612 and S613, reference may be made to steps S607 and S608, which will not be repeated here.

It can be understood that, in this embodiment 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 upgraded smoothly.

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 realize the function of the upgraded first component. At this time, steps S614 and S615 can be performed to facilitate the user to understand the situation, Improve user experience.

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

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.

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

After receiving the upgrade failure message, the OTA management module can notify the user of which component's hardware does not meet the hardware requirements, what is the current hardware information of the component, and what hardware requirements are required for the upgrade. In an 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 an on-board human-computer interaction system (such as an audio-visual system), and can also send a notification to a terminal device (such as a mobile phone, a laptop, etc.) that has established a communication connection with components such as the Tbox. The notification is presented to the user by the end device.

In the OTA-based upgrade method provided by the embodiment of the present application, when the first component is upgraded, it is checked whether the second component associated with the first component satisfies the first condition, so as to improve the successful installation and activation of the upgrade package of the first component The possibility of reducing the upgrade error rate and improving the user experience.

At the same time, the checking of the second component is performed by the OTA server without modifying the logic of the OTA management module, thereby reducing the requirements for the OTA management module.

The process of executing the method shown in FIG. 5b by the OTA management module will be described below with reference to FIG. 7 . FIG. 7 shows an interaction flowchart of an OTA-based upgrade method according to an embodiment of the present application. As shown in Figure 7, the OTA-based upgrade method includes:

Step S701, the OTA management module collects software information, firmware information and hardware information of each component in the vehicle.

Considering that the OTA management module needs to determine whether the second component satisfies the first condition according to 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 in-vehicle information. Software information, firmware information and hardware information of each component.

Step S702, the OTA management module reports the software information and/or firmware information of each component to the OTA server.

Considering that when the OTA server obtains or generates the policy package and the upgrade package, the software information and/or firmware information of the component needs to be used. The software information needs to be used when the software is upgraded, and the firmware information needs to be used when the firmware is upgraded. Therefore, 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, therefore, the OTA management module does not need to report the hardware information of each component to the OTA server, so as to save the communication resources between the OTA management module and the OTA server and the OTA server's communication resources. storage resources.

Step S703, the OTA server obtains the first policy package corresponding to the first component.

Step S703 may refer to step S603 and will not be repeated here.

Step S704, the OTA server sends the first policy package to the OTA management module.

Since the OTA server does not check whether the second component satisfies the first condition, after acquiring the first policy package, the OTA server can directly send the first policy package to the OTA management module.

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.

Through step S701, the OTA management module collects the information of each component in the vehicle. Therefore, the OTA management module can find the information of each second component associated with the first component in the collected information according to the identifier of each second component. In this step, the found information of the second component may be one or more of software information, firmware information and hardware information. For this step, reference may be made to step S604, which will not be repeated here.

Step S706, the OTA management module determines whether the second component satisfies the first condition according to the found information of the second component.

Step S706 may refer to step S605, which will not be repeated here.

If the second component associated with the first component satisfies the first condition, it indicates that the first component has the upgrade condition, the first component can be upgraded, and steps S707 and S708 can be executed at this time.

Step S707, when the first policy package instructs to perform an upgrade operation of the first component, the OTA management module sends an upgrade instruction to the OTA upgrade module deployed by the first component.

Step S708, after receiving the upgrade instruction, the OTA upgrade module upgrades the first component.

For steps S707 and S708, reference may be made to steps S607 and S608, which will not be repeated here.

If 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 be upgraded only after the second component is upgraded, and steps S709 to S713 may be performed at this time.

Step S709, the OTA management module sends a first request to the OTA server, where the first request is used to request to upgrade the second component.

In one example, the first request includes identifiers of one or more second components, as well as current software version information and required software version information of each second component (which can be obtained from the first condition).

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.

After receiving the first request, the OTA server may obtain the upgrade package and the policy package of each second component from the software repository according to the software version information required by each second component and the current software version information.

Step S711, when the second policy package instructs to perform 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 The second component satisfies the first condition.

In one example, the OTA management module may send an upgrade instruction to the OTA upgrade module deployed on each second component according to the upgrade sequence indicated by the second policy package. After receiving the upgrade instruction, the OTA upgrade module deploying the second component can upgrade the second component. For the software upgrade method of the second component, reference may be made to the software upgrade method of the first component, which will not be repeated here.

Step S711 may refer to step S611, which will not be repeated here.

Step S712, when the first policy package instructs to perform an upgrade operation of the first component, the OTA management module sends an upgrade instruction to the OTA upgrade module deployed by the first component.

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

Step S712 and step S713 can refer to step S607 and step S608, which will not be repeated here.

In the case that 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 realize the function of the upgraded first component, and step S714 may be executed at this time.

Step S714, the OTA server sends an upgrade failure notification to the user.

In an example, the upgrade failure notification 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 can notify the user through an on-board human-computer interaction system (such as an audio-visual system), and can also send the notification 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 notification is presented to the user by the electronic device.

In the OTA-based upgrade method provided by this embodiment of the present application, when upgrading a first component, it is checked whether the second component satisfies the first condition according to the information of the second component associated with the first component, so as to ensure the upgrade package of the first component. The successful installation and activation reduces the upgrade error rate and improves the user experience.

At the same time, the checking of whether the second component meets the first condition is performed by the OTA management module, which can reduce the workload of the OTA server, which is beneficial for multiple vehicles (eg, vehicle groups) to perform OTA upgrades at the same time.

The process of executing the method shown in FIG. 5b by the OTA upgrade module will be described below with reference to FIG. 8 . FIG. 8 shows an interaction flowchart of an OTA-based upgrade method according to an embodiment of the present application. As shown in Figure 8, the OTA-based upgrade method includes:

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

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

Considering that neither the OTA management module nor the OTA server need to check the hardware of the second component, 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.

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

Step S803 may refer to step S603, which will not be repeated here.

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

Step S805, when the first policy package instructs to perform the upgrade operation of the first component, the OTA management module sends the upgrade instruction and the first policy package to the OTA upgrade module deployed by the first component.

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.

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

In one example, the OTA upgrade module may send a second request to the OTA management module, wherein the second request is used to obtain one or more of software information, firmware information and hardware information of the second component, and the second request Include the identification of one or more second components. After receiving the second request, the OTA management module can obtain software information, firmware information and hardware information of the corresponding second component through the corresponding OTA upgrade module according to the identifier of the second component included in the second request. Then, the OTA management module may send the acquired software information, firmware information and hardware information to the OTA upgrade module deployed by the first component. In a possible implementation manner, in step S801, the OTA management module may not only collect the software information and firmware information of each component, but also the hardware information of each component of the mobile phone. In this way, after receiving the second request, the OTA management module may , the software information, firmware information and hardware information of the second component are searched locally without interacting with the OTA upgrade module deployed by the second component, which can save time.

Step S807, the OTA upgrade module determines whether the second component satisfies the first condition according to the acquired information of the second component.

If the second component associated with the first component satisfies the first condition, it indicates that the first component has the upgrade condition, the first component can be upgraded, and step S808 can be performed at this time.

Step S808, the OTA upgrade module upgrades the first component.

If 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 be upgraded only after the second component is upgraded, and steps S809 to S814 may be performed at this time.

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

Step S810, the OTA management module sends a first request to the OTA server.

Step S809 and step S810 may refer to step S709, which will not be repeated here.

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.

Step S811 may refer to step S710, which will not be repeated here.

Step S812, when the second policy package instructs to perform 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 software information and/or firmware information do not meet the first condition. The second component satisfies the first condition.

Step S813, the OTA management module sends a second component upgrade completion message to the OTA upgrade module deployed on the first component.

Step S814, when the OTA upgrade module receives the second component upgrade completion message, it upgrades the first component.

For steps S812 and S813, reference may be made to steps S807 and S808, which will not be repeated here.

In the case that 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 realize the function of the upgraded first component. In this case, steps S815 and S816 may be performed.

Step S815, the OTA upgrade module sends an upgrade failure message to the OTA management module.

Step S815 may refer to step S614, which will not be repeated here.

Step S816, after receiving the upgrade failure message, the OTA management module notifies the user.

Step S816 may refer to step S615, which will not be repeated here.

In the OTA-based upgrade method provided by the embodiment of the present application, when upgrading the software of the first component, it is checked whether the second component associated with the first component satisfies the first condition, so as to ensure the successful installation of the upgrade package of the first component and activation, which reduces the upgrade error rate and improves the user experience.

At the same time, the check of whether the second component meets the first condition is performed by the OTA upgrade module, which can reduce the workload of the OTA server and the workload of the OTA management module, which is conducive to the synchronous upgrade of multiple components in the vehicle, especially the overall car upgrade.

It should be noted that, before the OTA server sends a policy package (for example, a first policy package, a second policy package, etc.) or an upgrade package (for example, an upgrade package for the first component, an upgrade package for the second component, etc.) to the OTA management module, Policy packages and upgrade packages need to be signed. 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 then performs subsequent processing after the signature verification is passed. Likewise, before sending the policy package or the upgrade package to the OTA upgrade module, the OTA management module needs 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 is passed. In this way, data security can be improved and the possibility of upgrade errors can be reduced.

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

The acquisition module 91 is used to acquire the information of the second part associated with the first part; the determination module 92 is used to determine whether the second part satisfies the first condition according to the information of the second part acquired by the acquisition module 91, and the first condition is When upgrading the first component, the second component needs to meet the conditions; the first upgrade module 93 is configured to upgrade the first component through OTA when the determination module 92 determines that the second component meets the first condition.

In a possible implementation manner, the first condition is that when the first component is upgraded, the information of the second component satisfies the matching range of the information of the second component required when the first component is upgraded.

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

In a possible implementation manner, the apparatus 90 further includes:

The second upgrade module is configured to upgrade the second component so that the second component meets the first condition when the software information and/or firmware information in the information of the second component does not meet the first condition.

In a possible implementation manner, the apparatus 90 further includes:

The notification module is configured to notify the on-board upgrade failure when the hardware information in the information of the second component does not meet the first condition.

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

Embodiments of the present application provide a computer program product, including computer-readable codes, or a non-volatile computer-readable storage medium carrying computer-readable codes, when the computer-readable codes are stored in a processor of an electronic device When running in the electronic device, the processor in the electronic device executes the above method.

An embodiment of the present application provides a software upgrade apparatus, including a memory and a processor, where the memory stores computer program instructions, and the processor executes the computer program instructions to execute the above method.

In a first possible implementation manner of the software upgrade apparatus, the apparatus further includes a transceiver for receiving a policy package, an upgrade package, an upgrade failure message or information of the second component, or for sending an upgrade instruction, At least one of upgrade failure notification, etc.

The above software upgrading apparatus can be applied to terminal equipment in the form of, but not limited to, intelligent networked vehicles, robots, and smart homes. When applied to an ICV, the software upgrade device may be the ICV itself, or a component of the ICV, such as a central gateway, a telematics BOX (T-box) , Human-Machine Interaction (HMI), Mobile Data Controller (MDC), Advanced Driving Assistant System (ADAS) or Electronic Control Unit (ECU), Or it is a sub-device in the above-mentioned components, or it can be an independent device in the intelligent networked vehicle in addition to the above-mentioned components.

Embodiments of the present application provide a software upgrade apparatus, including a memory and a processor, where the memory stores computer program instructions, and the processor executes the computer program instructions to execute the above method.

In a first possible implementation manner of the software upgrade apparatus, the apparatus further includes a transceiver for receiving the information of the second component, or for sending at least one of an upgrade package, a policy package, an upgrade failure message, etc. one.

The above-mentioned software upgrading apparatus can be applied to the network side, for example, exists in the form of a server on the network side.

Embodiments of the present application provide a terminal software upgrade system, including the above software upgrade apparatus applicable to a terminal device and the above software upgrade apparatus applicable to a network side.

Embodiments of the present application provide a computer-readable storage medium, including computer program instructions, which, when executed by a processor, cause the software upgrade apparatus to execute the above method.

An embodiment of the present application provides an electronic device, the electronic device includes a processor, and the processor is configured to support the electronic device to perform corresponding functions in the above method. The electronic device may also include a memory for coupling with the processor that holds program instructions and data necessary for the electronic device. The electronic device may also include a communication interface for the electronic device to communicate with other devices or a communication network.

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

In embodiments of the present application, a computer-readable storage medium may be a tangible device that can hold and store instructions for use by the instruction execution device. The computer-readable storage medium may be, for example, but 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 (a non-exhaustive list) of computer-readable storage media include: portable computer disks, hard disks, random access memory (RAM), read only memory (ROM), erasable programmable read-only memory (Electrically Programmable Read-Only-Memory, EPROM or flash memory), static random access memory (Static Random-Access Memory, SRAM), portable compact disk read-only memory (Compact Disc Read-Only Memory, CD - ROM), Digital Video Disc (DVD), memory sticks, floppy disks, mechanically encoded devices, such as punch cards or raised structures in grooves on which instructions are stored, and any suitable combination of the foregoing .

Computer readable program instructions or code described herein may be downloaded to various computing/processing devices from a computer readable storage medium, or to an external computer or external storage device over a network such as the Internet, a local area network, a wide area network and/or a wireless network. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and/or edge servers. A network adapter card or network interface in each computing/processing device receives computer-readable program instructions from a network and forwards the computer-readable program instructions for storage in a computer-readable storage medium in each computing/processing device .

Computer program instructions for carrying out 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 in one or more source or object code written in any combination of 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 execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer, or entirely on the remote computer or server implement. In the case of a remote computer, the remote computer may be connected to the user's computer through any kind of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or, may be connected to an external computer (eg, use an internet service provider to connect via the internet). In some embodiments, electronic circuits, such as programmable logic circuits, Field-Programmable Gate Arrays (FPGA), or Programmable Logic Arrays (Programmable Logic Arrays), are personalized by utilizing state information of computer-readable program instructions. Logic Array, PLA), the electronic circuit can execute computer readable program instructions to implement various aspects of the present application.

Aspects of the present application are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the present application. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer readable program instructions.

These computer readable program instructions may be provided to the processor of a general purpose computer, special purpose computer or other programmable data processing apparatus to produce a machine that causes the instructions when executed by the processor of the computer or other programmable data processing apparatus , resulting in means for implementing the functions/acts specified in one or more blocks of the flowchart and/or block diagrams. These computer readable program instructions can also be stored in a computer readable storage medium, these instructions cause a computer, programmable data processing apparatus and/or other equipment to operate in a specific manner, so that the computer readable medium on which the instructions are stored includes An article of manufacture comprising instructions for implementing various aspects of the functions/acts specified in one or more blocks of the flowchart and/or block diagrams.

Computer readable program instructions can also be loaded onto a computer, other programmable data processing apparatus, or other equipment to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other equipment to produce a computer-implemented process , thereby causing instructions executing on a computer, other programmable data processing apparatus, or other device to implement the functions/acts specified in one or more blocks of the flowcharts and/or block diagrams.

The flowchart 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 block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more functions for implementing the specified logical function(s) executable instructions. In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved.

It is also noted that each block of the block diagrams and/or flowchart illustrations, and combinations of blocks in the block diagrams and/or flowchart illustrations, can be implemented in hardware (eg, circuits or ASICs (Application) that perform the corresponding functions or actions. Specific Integrated Circuit, application-specific integrated circuit)), or can be implemented by a combination of hardware and software, such as firmware.

While the invention has been described herein in connection with various embodiments, those skilled in the art will understand and understand from a review of the drawings, the disclosure, and the appended claims in practicing the claimed invention. Other variations of the disclosed embodiments are implemented. In the claims, the word "comprising" does not exclude other components or steps, and "a" or "an" does not exclude a plurality. A single processor or other unit may fulfill the functions of several items recited in the claims. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that these measures cannot be combined to advantage.

Various embodiments of the present application have been described above, and the foregoing descriptions are exemplary, not exhaustive, and not limiting of the disclosed embodiments. Numerous modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terminology used herein was chosen to best explain the principles of the various embodiments, the practical application or improvement over the technology in the marketplace, or to enable others of ordinary skill in the art to understand the various embodiments disclosed herein.

The above are only specific embodiments of the present invention, but the protection scope of the present invention is not limited thereto. Any person skilled in the art can easily think of changes or substitutions within the technical scope disclosed by the present invention. should be included within the protection scope of the present invention. Therefore, the protection scope of the present invention should be based on the protection scope of the claims.

Claims

An upgrade method based on over-the-air technology OTA, characterized in that the method comprises:

obtain information about the second part associated with the first part;

Determine whether the second component satisfies 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 the first component is upgraded;

If the second component satisfies the first condition, the first component is upgraded through the OTA.
The method according to claim 1, wherein the first condition is that when the first component is upgraded, the information of the second component satisfies the second component required when the first component is upgraded The matching range of the information.
The method according to claim 1 or 2, wherein the information of the second component is at least one of hardware information, software information and firmware information.
The method according to any one of claims 1-3, wherein the method further comprises:

If the software information and/or firmware information in the information of the second component does not satisfy the first condition, the second component is upgraded so that the second component satisfies the first condition.
The method according to any one of claims 1-4, wherein the method further comprises:

In the case that the hardware information in the information of the second component does not satisfy the first condition, the vehicle end is notified that the upgrade fails.
An upgrade device based on an over-the-air download technology OTA, characterized in that the device comprises:

an acquisition module for acquiring the information of the second part associated with the first part;

a determining module, configured to determine whether the second part satisfies a first condition according to the information of the second part acquired by the acquiring module, and the first condition is that when the first part is upgraded, the second part needs to satisfy conditions of;

A first upgrade module, configured to upgrade the first part through the OTA when the determination module determines that the second part satisfies the first condition.
The device according to claim 6, wherein the first condition is that when the first component is upgraded, the information of the second component satisfies the second component required when the first component is upgraded The matching range of the information.
The apparatus according to claim 6 or 7, wherein the information of the second component is at least one of hardware information, software information and firmware information.
The device according to any one of claims 6-8, wherein the device further comprises:

A second upgrade module, configured to upgrade the second component so that the second component satisfies all conditions when the software information and/or firmware information in the information of the second component does not satisfy the first condition. the first condition.
The device according to any one of claims 6-9, wherein the device further comprises:

The notification module is configured to notify the vehicle-end upgrade failure when the hardware information in the information of the second component does not meet the first condition.
An electronic device, comprising:

processor;

memory for storing instructions executable by the processor;

wherein the processor is configured to implement the method of any one of claims 1 to 5 when executing the instructions.
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 described in any one of claims 1 to 5 is implemented.
A computer program product, characterized by comprising computer-readable codes, or a non-volatile computer-readable storage medium carrying computer-readable codes, when the computer-readable codes are executed in a processor of an electronic device A method as claimed in any one of claims 1 to 5 is implemented.