CN112913190A - 基于空中下载技术ota的升级方法及装置 - Google Patents

Abstract

本申请实施例提供一种基于空中下载技术OTA的升级方法及装置，所述方法包括：获取与第一部件关联的第二部件的信息；根据所述第二部件的信息确定所述第二部件是否满足第一条件，所述第一条件为升级所述第一部件时，所述第二部件需要满足的条件；在所述第二部件满足所述第一条件的情况下，通过所述OTA升级所述第一部件。根据本公开实施例提供的基于空中下载技术OTA的升级方法及装置，能够提高OTA升级的可靠性，提升用户体验。

Description

基于空中下载技术OTA的升级方法及装置

技术领域

本申请涉及通信技术领域，尤其涉及一种基于空中下载技术OTA的升级方法及装置。

背景技术

空中下载技术(Over the Air technology，OTA)是一种通过无线网络进行数据下载的技术，现已被广泛应用于智能电视、手机、平板电脑、机顶盒等设备的网络升级中。随着智能网联汽车的发展，OTA在线升级成为了汽车的重要功能，原始设备制造商(OriginalEquipment Manufacture，OEM)厂商通过OTA升级汽车的相关软件和固件，有利于OEM厂商减少召回成本，快速响应需求、提升用户体验。然而，某些软件包的使用需要依赖相关软件或硬件，以确保软件包的正确安装和使用。

因此，亟需解决因相关软件或硬件不匹配而导致的升级失败的问题，进而提高OTA升级的可靠性。

发明内容

有鉴于此，提出了一种基于空中下载技术OTA的升级方法及装置，能够解决因相关软件或硬件不匹配而导致的升级失败的问题，进而提升OTA升级的可靠性。

第一方面，本申请的实施例提供了一种基于OTA的升级方法，所述方法包括：获取与第一部件关联的第二部件的信息；根据所述第二部件的信息确定所述第二部件是否满足第一条件，所述第一条件为升级所述第一部件时，所述第二部件需要满足的条件；在所述第二部件满足所述第一条件的情况下，通过所述OTA升级所述第一部件。

在本申请实施例中，通过在升级第一部件时，第一部件关联的第二部件的信息进行检查；在第二部件的信息满足第一部件升级时所需的第二部件的信息的匹配范围时，升级第一部件，从而降低了第一部件升级失败，以及进行第一部件升级后出现部分功能不可用、易出错等问题的可能，提高了OTA升级的可靠性，提升了用户体验。

根据第一方面，在一种可能的实现方式中，所述第一条件为在升级所述第一部件时，所述第二部件的信息满足于所述第一部件升级时所需的第二部件的信息的匹配范围。这样，可以提高第一条件的灵活性和准确性。

根据第一方面或者第一方面的一种可能的实现方式，在所述基于OTA的升级方法的第二种可能的实现方式中，所述第二部件的信息为硬件信息、软件信息和固件信息中的至少一项。

根据第一方面，在第一种可能的实现方式中，所述方法还包括：在所述第二部件的信息中的软件信息和/或固件信息不满足所述第一条件的情况下，则升级所述第二部件以使所述第二部件满足所述第一条件。

这样，通过自动升级第二部件实现第一部件的升级，可以在用户无感知的情况下，完成基于OTA的第一部件的升级，有利于提升用户体验。

根据一方面，在一种可能的实现方式，在所述基于OTA的升级方法的第四种可能的实现方式中，所述方法还包括：

在所述第二部件的信息中的硬件信息不满足所述第一条件的情况下，则通知车端升级失败。这样，可以便于用户了解升级失败的原因，便于用户更换硬件。

第二方面，本申请的实施例提供了一种基于OTA的升级装置，所述装置包括：

获取模块，用于获取与第一部件关联的第二部件的信息；

确定模块，用于根据所述获取模块获取的第二部件的信息确定所述第二部件是否满足第一条件，所述第一条件为升级所述第一部件时，所述第二部件需要满足的条件；第一升级模块，用于在所述确定模块确定第二部件满足所述第一条件的情况下，通过所述OTA升级所述第一部件。

根据第二方面，在一种可能的实现方式中，所述第一条件为在升级所述第一部件时，所述第二部件的信息满足于所述第一部件升级时所需的第二部件的信息的匹配范围。

根据第二方面，在一种可能的实现方式中，在所述基于OTA的升级装置的第二种可能的实现方式中，所述第二部件的信息为硬件信息、软件信息和固件信息中的至少一项。

根据第二方面，在一种可能的实现方式中，所述装置还包括：

第二升级模块，用于在所述第二部件的信息中的软件信息和/或固件信息不满足所述第一条件的情况下，则升级所述第二部件以使所述第二部件满足所述第一条件。

根据第二方面，或者以上第二方面的任意一种可能的实现方式，在所述基于OTA的升级装置的第四种可能的实现方式中，所述装置还包括：

通知模块，用于在所述第二部件的信息中的硬件信息不满足所述第一条件的情况下，则通知车端升级失败。

第三方面，本申请的实施例提供了一种电子设备，该电子设备可以执行上述第一方面或者第一方面的多种可能的实现方式中的一种或几种的基于OTA的升级方法。

第四方面，本申请的实施例提供了一种计算机程序产品，包括计算机可读代码，或者承载有计算机可读代码的非易失性计算机可读存储介质，当所述计算机可读代码在电子设备中运行时，所述电子设备中的处理器执行上述第一方面或者第一方面的多种可能的实现方式中的一种或几种的基于OTA的升级方法。

第五方面，本申请提供一种软件升级装置，包括存储器和处理器，所述存储器存储计算机程序指令，所述处理器运行所述计算机程序指令以执行第一方面或以上第一方面的任意一种实现方式的操作。

根据第五方面，在所述软件升级装置的第一种可能的实现方式中，所述装置还包括收发器，用于接收策略包、升级包、升级失败消息或第二部件的信息，或者用于发送升级指示、升级失败通知等中的至少一项。

上述第五方面，或第五方面的任意一种实现方式所描述的软件升级装置，可应用于包括但不限于智能网联车、机器人和智能家居等形式的终端设备。当应用于智能网联车时，所述软件升级装置可以是智能网联车本身，或者是智能网联车的一个部件，例如中央网关、车联网车端通信终端(Telematics BOX，T-box)、人机交互控制器(Human-MachineInteraction，HMI)、移动数据中心(Mobile Data Controller，MDC)、高级驾驶辅助系统(Advanced Driving Assistant System，ADAS)或电子控制单元(Electronic ControlUnit，ECU)，又或者是上述部件内的一个子装置，还可以是除了上述部件以外智能网联车内的一个独立的装置。

第六方面，本申请提供一种软件升级装置，包括存储器和处理器，所述存储器存储计算机程序指令，所述处理器运行所述计算机程序指令以执行第一方面或第一方面的任意一种实现方式的操作。

根据第六方面，在所述软件升级装置的第一种可能的实现方式中，所述装置还包括收发器，用于接收第二部件的信息，或者用于发送升级包、策略包、升级失败消息等中的至少一项。

上述第六方面，或第六方面的任意一种实现方式所描述的软件升级装置，可应用于网络侧，例如以网络侧的一个服务器形式存在。

第七方面，本申请提供一种终端软件升级系统，包括第五方面或以上第五方面的任意一种实现方式的软件升级装置和第六方面或以上第六方面的任意一种实现方式的软件升级装置。

第八方面，本申请提供一种计算机可读存储介质，包括计算机指令，当所述计算机指令在被处理器运行时，使得所述软件升级装置执行第一方面或以上第一方面的任意一种实现方式的方法。

第九方面，本申请提供一种电子设备，该电子设备中包括处理器，处理器被配置为支持该电子设备执行第一方面提供的方法中相应的功能。该电子设备还可以包括存储器，存储器用于与处理器耦合，其保存该电子设备必要的程序指令和数据。该电子设备还可以包括通信接口，用于该电子设备与其他设备或通信网络通信。

第十方面，本申请提供了一种芯片系统，该芯片系统包括处理器，用于电子设备或服务器实现上述第一方面中所涉及的功能，例如，例如接收或处理上述方法中所涉及的数据和/或信息。在一种可能的设计中，所述芯片系统还包括存储器，所述存储器，用于保存电子设备或服务器必要的程序指令和数据。该芯片系统，可以由芯片构成，也可以包含芯片和其他分立器件。

本申请的这些和其他方面在以下(多个)实施例的描述中会更加简明易懂。

附图说明

图1示出本申请实施例提供的一种网络架构的示意图；

图2示出本申请实施例提供的一种网络架构的示意图；

图3示出用于部署OTA服务器的电子设备的结构示意图；

图4示出Tbox的结构示意图；

图5a提供一种软件升级的流程示意图；

图5b示出根据本申请实施例的基于OTA的升级方法的流程图；

图6示出根据本申请实施例的基于OTA的升级方法的交互流程图；

图7示出根据本申请实施例的基于OTA的升级方法的交互流程图；

图8示出根据本申请实施例的基于OTA的升级方法的交互流程图；

图9示出根据本申请实施例的基于OTA的升级装置的结构示意图。

具体实施方式

以下将参考附图详细说明本申请的各种示例性实施例、特征和方面。附图中相同的附图标记表示功能相同或相似的元件。尽管在附图中示出了实施例的各种方面，但是除非特别指出，不必按比例绘制附图。

在这里专用的词“示例性”意为“用作例子、实施例或说明性”。这里作为“示例性”所说明的任何实施例不必解释为优于或好于其它实施例。以下，术语“第一”、“第二”仅用于描述目的，而不能理解为暗示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征。在本申请实施例的描述中，除非另有说明，“多个”的含义是两个或两个以上。

另外，为了更好的说明本申请，在下文的具体实施方式中给出了众多的具体细节。本领域技术人员应当理解，没有某些具体细节，本申请同样可以实施。在一些实例中，对于本领域技术人员熟知的方法、手段、元件和电路未作详细描述，以便于凸显本申请的主旨。

图1示出本申请实施例提供的一种网络架构的示意图。如图1所示，该网络架构可以包括空中下载技术(Over the Air technology，OTA)服务器、无线通信链路和车辆。在一个示例中，车辆可以通过移动通信网络(例如2G/3G/4G/5G网络)与OTA服务器进行通信，也可以通过无线局域网络(Wireless local area networks，WLAN)与OTA服务器进行通信。本申请实施例对无线通信链路不做限制。

如图1所示，车辆中至少包括网关(GateWay，GW)、移动数据中心(Mobile DataCenter，MDC)、人机交互系统(Human-Machine Interaction，HMI)、远程信息控制单元(Telematics Control Unit，TCU)、汽车盒子(Telematics box，Tbox)、电子控制单元(Electronic Control Unit，ECU)等部件。

其中，GW是整车电子电气架构中的核心部件，其作为整车网络的数据交互枢纽，可将控制区域网络(Controller Area Network，CAN)、局域互联网络(Local InterconnectNetwork，LIN)、多媒体软件升级(Media Oriented System Transport，MOST)网络等网络数据在不同网络中进行路由。MDC是车辆的智能车载计算平台，MDC可以用于实现车辆的自动驾驶功能。HMI是车辆的信息娱乐系统。TCU和Tbox主要用于和车辆外部设备(例如手机、后台系统等)进行通信。ECU是车辆专用微机控制器。ECU包括但不限于整车集成单元(VehicleIntegrated/Intergration Unit，VIU)、座舱域控制器(Cockpit Domain Controller，CDC)和整车域控制器(Vehicle Domain Controller，VDC)等。在本申请实施例中，待升级的第一部件包括但不限于上述GW、MDC、HMI、TCU、Tbox和ECU，待升级的第一部件可以包括上述GW、MDC、HMI、TCU、Tbox和ECU中的一者或多者。

在整车OTA升级中通常涉及车辆中多个部件的升级，因此需要一个OTA管理模块(可以称为OTA Master模块)来协调这多个部件的升级。OTA管理模块可以运行在车辆的GW、Tbox等部件上，协调其他部件的OTA升级模块(可以称为OTA Slave模块)，共同完成整车升级。

图2示出本申请实施例提供的一种网络架构的示意图。如图2所示，车辆的GW中部署了OTA管理模块，车辆的其他部件中部署了OTA升级模块。其中，OTA管理模块可以协调各部件部署的OTA升级模块，共同完成整车OTA升级。在OTA服务器和OTA管理模块之间发送消息之前，OTA管理模块和OTA升级模块需要进行一些配置，比如配置证书、私钥等。基于配置的信息，OTA服务器和OTA管理模块之间可以建立安全通道，例如超文本传输安全协议(Hyper Text Transfer Protocol over SecureSocket layer，HTTPS)、传输层安全协议(Transport Layer Security，TLS)或者数据包传输层安全性协议(Datagram TransportLayer Security，DTLS)等安全通道，以便在OTA服务器与OTA管理模块之间安全的传输信息，例如，安全的传输本申请实施例中涉及的策略包、升级包、第二部件的信息以及第一条件等。

在本申请实施例中，OTA服务器可以部署在具有无线通信功能和存储功能的电子设备上，还可以部署在云上的虚拟机(Virtual Machine，VM)或者容器上，其中云可以是多个电子设备组成的集群。图3示出用于部署OTA服务器的电子设备的结构示意图。

如图3所示，电子设备可以包括至少一个处理器301，存储器302、输入输出设备303以及总线304。下面结合图3对电子设备的各个构成部件进行具体的介绍：

处理器301是电子设备的控制中心，可以是一个处理器，也可以是多个处理元件的统称。例如，处理器301是一个CPU，也可以是特定集成电路(Application SpecificIntegrated Circuit，ASIC)，或者是被配置成实施本申请实施例的一个或多个集成电路，例如：一个或多个微处理器(Digital Signal Processor，DSP)，或，一个或者多个现场可编程门阵列(Field Programmable Gate Array，FPGA)。

其中，处理器301可以通过运行或执行存储在存储器302内的软件程序，以及调用存储在存储器302内的数据，执行电子设备的各种功能。

在具体的实现中，作为一种实施例，处理器301可以包括一个或多个CPU，例如图中所示的CPU 0和CPU 1。

在具体实现中，作为一种实施例，电子设备可以包括多个处理器，例如图3中所示的处理器301和处理器305。这些处理器中的每一个可以是一个单核处理器(single-CPU)，也可以是一个多核处理器(multi-CPU)。这里的处理器可以指一个或多个设备、电路、和/或用于处理数据(例如计算机程序指令)的处理核。

存储器302可以是只读存储器(Read-Only Memory，ROM)或可存储静态信息和指令的其他类型的静态存储设备，随机存取存储器(Random Access Memory，RAM)或者可存储信息和指令的其他类型的动态存储设备，也可以是电可擦可编程只读存储器(ElectricallyErasable Programmable Read-Only Memory，EEPROM)、只读光盘(Compact Disc Read-Only Memory，CD-ROM)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。存储器302可以是独立存在，通过总线304与处理器301相连接。存储器302也可以和处理器301集成在一起。在本申请实施例中，存储器可以用于策略包和升级包等。

输入输出设备303，用于与其他设备或通信网络通信。如用于与以太网，无线接入网(Radio access network，RAN)，无线局域网(Wireless Local Area Networks，WLAN)等通信网络通信。输入输出设备303可以包括基带处理器的全部或部分，以及还可选择性地包括无线射频(Radio Frequency，RF)处理器。RF处理器用于收发RF信号，基带处理器则用于实现由RF信号转换的基带信号或即将转换为RF信号的基带信号的处理。

在具体实现中，作为一种实施例，输入输出设备303可以包括发射器和接收器。其中，发射器用于向其他设备或通信网络发送信号，接收器用于接收其他设备或通信网络发送的信号。发射器和接收器可以独立存在，也可以集成在一起。在本申请实施例中，输入输出设备可以用于收发：策略包、升级包、第二部件的信息以及第一条件等。

总线304，可以是工业标准体系结构(Industry Standard Architecture，ISA)总线、外部设备互连(Peripheral Component Interconnect，PCI)总线或扩展工业标准体系结构(Extended Industry Standard Architecture，EISA)总线等。该总线可以分为地址总线、数据总线、控制总线等。为便于表示，图3中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

图3中示出的设备结构并不构成对电子设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

在本申请实施例中，Tbox部件既可用于部署OTA管理模块，也可以部署OTA升级模块。下面以Tbox为例，对车载部件的结构进行示例性说明。图4示出Tbox的结构示意图。

如图4所示，Tbox 40包括应用层微处理器单元(MicroProcessor Unit，MPU)41和微控制器单元(MicroController Unit，MCU)42。其中，MPU 41主要用来实现应用程序功能，MCU 42主要用来控制电源管理以及接入车辆CAN总线。MPU 41与MCU 42之间通过通用型输入输出(General Purpose Input Output，GPIO)接口以及串行外设接口(SerialPeripheral Interface，SPI)进行通信。

其中，MPU 41包括上位机411和无线通信模块412。其中，上位机411对应芯片功能层，无线通信模块412对应芯片无线通信层。

MPU 41还可以包括微处理器(未示出)，该微处理器可以包括一个或多个处理单元，例如：该微处理器包括应用处理器(application processor，AP)，调制解调处理器，图形处理器(graphics processing unit，GPU)，图像信号处理器(image signal processor,ISP)，控制器，存储器，视频编解码器，数字信号处理器(digital signal processor,DSP)，基带处理器，和/或神经网络处理器(Neural-network Processing Unit,NPU)等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。其中，控制器可以是MPU 41的神经中枢和指挥中心。控制器可以根据指令操作码和时序信号，产生操作控制信号，完成取指令和执行指令的控制。

微处理器中还可以设置存储器，用于存储指令和数据。在一些实施例中，微处理器中的存储器为高速缓冲存储器。该存储器可以保存微处理器刚用过或循环使用的指令或数据。如果微处理器需要再次使用该指令或数据，可从所述存储器中直接调用。避免了重复存取，减少了微处理器的等待时间，因而提高了系统的效率。

微处理器可以运行本申请实施例提供的基于OTA的升级方法，以便于降低升级出错率，提高用户体验。微处理器可以包括不同的器件，比如集成CPU和GPU时，CPU和GPU可以配合执行本申请实施例提供的基于OTA的升级方法，比如基于OTA的升级方法中部分算法由CPU执行，另一部分算法由GPU执行，以得到较快的处理效率。

当微处理器运行本申请实施例提供的基于OTA的升级方法后，无线通信模块412可以通过天线与OTA服务器建立连接，并根据本申请实施例提供的基于OTA的升级方法传输升级包和策略包等。

MPU 41还可以包括内部存储器(未示出)。内部存储器可以用于存储计算机可执行程序代码，所述可执行程序代码包括指令。微处理器通过运行存储在内部存储器的指令，从而执行MPU 41的各种功能应用以及数据处理。内部存储器可以包括存储程序区和存储数据区。其中，存储程序区可存储操作系统，应用程序的代码等。

内部存储器还可以存储本申请实施例提供的基于OTA的升级方法对应的一个或多个计算机程序。该一个或多个计算机程序被存储在上述存储器中并被配置为被上述一个或多个微处理器执行，该一个或多个计算机程序包括指令，上述指令可以用于执行根据本申请实施例的基于OTA的升级方法的各个步骤。

无线通信模块412可以提供应用在Tbox 40的包括长期演进(Long TermEvolution，LTE)、网络协议多媒体子系统(IP Multimedia Subsystem，IMS)、新无线(NewRadio，NR)通信技术，或者第五代通信技术(the 5Generation Mobile CommunicationTechnology，5G)等无线通信的解决方案。无线通信模块412可以包括至少一个滤波器，开关，功率放大器，低噪声放大器(low noise amplifier，LNA)等。无线通信模块412可以由天线(未示出)接收电磁波，并对接收的电磁波进行滤波，放大等处理，传送至调制解调处理器进行解调。无线通信模块412还可以对经调制解调处理器调制后的信号放大，经天线转为电磁波辐射出去。在一些实施例中，无线通信模块412的至少部分功能模块可以被设置于微处理器中。在一些实施例中，无线通信模块412的至少部分功能模块可以与微处理器的至少部分模块被设置在同一个器件中。在本申请实施例中，无线通信模块412可以用于与OTA服务器以及其它电子设备(例如手机、平板、个人计算等)进行信息交互。例如，无线通信模块412可以用于与OTA服务器之间进行软件信息、固件信息、硬件信息、升级包以及策略包的传输。无线通信模块412还可以用于与其他电子设备之间进行硬件信息不符合对应的硬件需求的通知的传输。

调制解调处理器可以包括调制器和解调器。其中，调制器用于将待发送的低频基带信号调制成中高频信号。解调器用于将接收的电磁波信号解调为低频基带信号。随后解调器将解调得到的低频基带信号传送至基带处理器处理。低频基带信号经基带处理器处理后，被传递给应用处理器。应用处理器通过音频设备(不限于扬声器、麦克风等)输出声音信号，或通过显示屏显示图像或视频。在一些实施例中，调制解调处理器可以是独立的器件。在另一些实施例中，调制解调处理器可以独立于微处理器，与无线通信模块412或其他功能模块设置在同一个器件中。

MCU 42可以通过以太网连接车机，还可以通过CAN网络连接车身中的其他部件，例如设置在车身上的传感器。

可以理解的是，本申请实施例示意的结构并不构成对Tbox的具体限定。在本申请另一些实施例中，Tbox可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。

图5a提供一种软件升级的流程示意图。该流程可以应用于图2所示的架构。如图5a所示，软件升级流程包括：1、OTA服务器对升级包进行签名；2、OTA服务器通过安全通道下发签名的升级包；3、OTA管理模块通过安全通道下载签名的升级包；4、OTA管理模块验证升级包的签名；5、签名验证通过后，OTA管理模块将升级包拆解并分发至对应部件的OTA升级模块；6、OTA升级模块接收OTA管理模块分发的升级包；7、OTA升级模块按照OTA管理模块的指示安装和激活升级包。

在实施中，在OTA服务器向OTA管理模块下发签名的升级包时，还会向OTA管理模块下发策略包，该策略包中指示了车辆中各部件的软件升级顺序。在根据策略包确定执行某个部件的升级操作时，例如确定执行第一部件的升级操作时，OTA管理模块可以向第一部件上部署的OTA升级模块发送软件升级指示。第一部件的OTA升级模块接收到软件升级指示后，执行升级包的安装和激活操作，从而实现第一部件的升级。在升级完成之后，OTA升级模块可以向OTA管理模块发送升级完成的消息，以便于OTA管理模块可以确定升级进度，在一个示例中，OTA升级模块接收到第一部件升级完成的消息后，可以确定执行另一部件的软件升级操作，在又一示例中，OTA接收到第一部件升级完成的消息后，可以确定全部升级完成。

然而，第一部件升级时，并未考虑其升级对相关部件的需求。在实际中，某些部件的升级包的使用需要其他部件的软硬件或者固件满足一定的条件，比如，新的自动驾驶功能可能需要相关传感器在特定的软件版本和硬件版本才能使用。在相关传感器未在特定的软件版本和/或硬件版本的情况下，即使升级了新的自动驾驶功能，该功能也可能无法使用，例如可能会提示未检测到传感器，或者因未收到传感器的检测数据而报错等。

因此，本申请实施例提供一种基于OTA的升级方法，能够为部件升级提供保障，提高部件升级成功的概率，从而提升用户体验。

本申请实施例提供的基于OTA的升级方法既可以实现针对整车的升级(即基于OTA对车辆中多个部件进行升级)，也可以实现针对车辆中单个部件的软件升级(即基于OTA对车辆中的任意一个部件进行升级)。在针对整车进行升级时，可以按照一定的升级顺序，对每个待升级的部件分别进行升级。

下面以第一部件为待升级的部件举例，对本申请实施例提供的基于OTA的升级方法进行说明。其中，第一部件可以为任意一个部件。第一部件可以为整车升级中需要升级的多个部件中的任意一个部件，也可以为单个被升级的部件。对于整车升级而言，其他需要升级的部件的升级方式与第一部件的升级方式相同，本申请实施例中不再赘述。

本申请实施例提供的基于OTA的升级方法可以应用于图2所示的架构中。该方法可以由OTA服务器、OTA管理模块和OTA升级模块中的任意一者执行。

图5b示出根据本申请实施例的基于OTA的升级方法的流程图。如图5b所示，该方法可以包括：

步骤S501，获取与第一部件关联的第二部件的信息。

在本申请实施例中，第一部件可以表示任意一个待升级的部件。第一部件关联的第二部件可以表示升级第一部件时需要满足一定条件的部件。

第一部件关联的第二部件可以有一个或多个。第一部件关联的第二部件中可以包括第一部件，也就是说，第一部件的升级可能需要第一部件自身满足一定的条件。第一部件关联的第二部件可以包括除第一部件以外的其他部件，也就是说，第一部件的软件升级可能需要除第一部件以外的其他部件满足一定的条件。

步骤S502，根据第二部件的信息确定第二部件是否满足第一条件。

在本申请实施例中，升级第一部件时第二部件需要满足的条件可以称为第一条件。也就是说，在第二部件满足第一条件时，可以实现对第一部件的升级，在第二部件不满足第一条件时，无法实现对第一部件的升级。

在实施中，可以根据第二部件的信息确定第二部件是否满足第一条件。其中，第二部件的信息为硬件信息、软件信息和固件信息中的至少一项。其中，硬件信息可以包括硬件版本号和/或硬件型号；软件信息可以包括软件版本号；固件信息可以包括固件版本号。相应的，第一条件可以为在升级第一部件时，第二部件的信息满足于所述第一部件升级时所需的第二部件的信息的匹配范围。也就是说，在升级第一部件时，若第二部件的信息满足于第一部件升级时所需的第二部件的信息的匹配范围，表明第二部件满足第一条件，此时可以实现对第一部件的升级；若第二部件的信息不满足于第一部件升级时所需的第二部件的信息的匹配范围，表明第二部件不满足第一条件，此时无法实现对第一部件的升级。

在本申请实施例中，第一部件升级时所需的第二部件的信息的匹配范围可以由OTA服务器或者内容分发网络(Content Delivery Network，CDN)生成。在一种可能的实现方式中，OTA服务器可以根据升级前第一部件的软件版本信息，确定升级后第一部件的软件版本信息；并根据升级后第一部件的软件版本信息生成第一部件升级时所需的第二部件的信息的匹配范围。或者，OTA服务器可以根据升级后第一部件的软件版本信息从CDN中获取第一部件升级时所需的第二部件的信息的匹配范围。在实施中，第一部件升级时所需的第二部件的信息的匹配范围可以包含在用于指示第一部件升级的第一策略包中。

第一部件升级时所需的第二部件的信息的匹配范围可以涉及一个或多个第二部件。针对涉及的一个或多个第二部件中的任意一个第二部件，第一部件升级时所需的第二部件的信息的匹配范围可以涉及该第二部件的硬件信息、软件信息和固件信息中的一者或多者。

在一种可能的实施方式中，第一部件升级时所需的第二部件的信息的匹配范围可以为第二部件A的硬件信息。也就是说，升级第一部件时，第二部件A的硬件信息需要满足第一部件升级时所需的第二部件A的硬件信息，才能实现第一部件的升级。

举例来说，第一部件从软件版本1.0升级到软件版本2.0时，需要的第二部件的信息的匹配范围可以为：第二部件A的硬件版本为3.0或者3.0以上。若升级第一部件时，第二部件A的硬件版本为2.0，则表明第二部件A不满足第一条件，无法实现第一部件的升级。若升级第一部件时，第二部件的硬件版本为3.0或者4.0，则表明第二部件A满足第一条件，可以实现第一部件的升级。假设第一部件从软件版本1.0升级到软件版本2.0，需要第二部件A的硬件版为3.0、硬件型号为1234或者1235。若升级第一部件时，第二部件A的硬件版本是3.0，且硬件型号为1234和1235中的一者的情况下，才能实现第一部件的升级。

在一种可能的实施方式中，第一部件升级时所需的第二部件的信息的匹配范围可以为第二部件A的软件信息。也就是说，升级第一部件时，第二部件A的软件信息需要满足第一部件升级时所需的第二部件A的软件信息，才能实现第一部件的升级。

举例来说，假设第二部件A的软件版本在4.0以下时，无法支持第一部件从软件版本1.0升级到软件版本2.0，而第二部件A的版本在6.0以上时，表明第一部件的软件版本已经升级到了2.0或者2.0以上的版本，第一部件的软件版本无需升级，也就是说，第一部件从软件版本1.0升级到软件版本2.0时，需要的第二部件的信息的匹配范围可以为：第二部件A的软件版本为4.0至6.0之间。若升级第一部件时，第二部件A的软件版本为4.0、5.0或者6.0，表明第二部件A满足第一条件，可以实现第一部件的升级。若升级第一部件时，第二部件A的软件版本为4.0以下(例如2.0、3.0、3.1或者3.22等)或者6.0以上(例如6.11、7.0、或者8.0等)，无法实现第一部件的升级。

在一种可能的实施方式中，第一部件升级时所需的第二部件的信息的匹配范围可以为第二部件A的固件信息。也就是说，升级第一部件时，第二部件A的硬件信息需要满足第一部件升级时所需的第二部件A的固件信息，才能实现第一部件的升级。

举例来说，第一部件从软件版本1.0升级到软件版本2.0时，需要的第二部件的信息的匹配范围可以为：第二部件A的固件版本为4.0、6.0或者8.0。若升级第一部件时，第二部件A的固件版本不是4.0、6.0和8.0中的一者，则无法实现第一部件的升级。又如，第一部件从软件版本1.0升级到软件版本2.0时，需要的第二部件的信息的匹配范围可以为：第二部件A的固件版本不为3.0。

在一种可能的实施方式中，第一部件升级时所需的第二部件的信息的匹配范围可以为第二部件A的硬件信息和软件信息。也就是说，升级第一部件时，第二部件A的硬件信息需要满足第一部件升级时所需的第二部件A的硬件信息，且第二部件A的软件信息需要满足第一部件升级时所需的第二部件A的软件信息，才能实现第一部件的升级。

举例来说，第一部件从软件版本1.0升级到软件版本2.0时，需要的第二部件的信息的匹配范围可以为：第二部件A的硬件版本为3.0或者5.0，硬件型号为1234，软件版本为2.0或者2.0以上。

在一种可能的实施方式中，第一部件升级时所需的第二部件的信息的匹配范围可以为第二部件A的硬件信息和固件信息。也就是说，升级第一部件时，第二部件A的硬件信息需要满足第一部件升级时所需的第二部件A的硬件信息，且第二部件A的固件信息需要满足第一部件升级时所需的第二部件A的固件信息，才能实现第一部件的升级。

举例来说，第一部件从软件版本1.0升级到软件版本2.0时，需要的第二部件的信息的匹配范围可以为：第二部件A的硬件型号为1234或者1235，固件版本为2.0。

在一种可能的实施方式中，第一部件升级时所需的第二部件的信息的匹配范围可以为第二部件A的软件信息和固件信息。也就是说，升级第一部件时，第二部件A的软件信息需要满足第一部件升级时所需的第二部件A的软件信息，且第二部件A的固件信息需要满足第一部件升级时所需的第二部件A的固件信息，才能实现第一部件的升级。

举例来说，第一部件从软件版本1.0升级到软件版本2.0时，需要的第二部件的信息的匹配范围可以为：第二部件A的软件版本为4.0或者4.0以上，固件版本为2.0。

在一种可能的实施方式中，第一部件升级时所需的第二部件的信息的匹配范围可以为第二部件A的硬件信息、软件信息和固件信息。也就是说，升级第一部件时，第二部件A的硬件信息需要满足第一部件升级时所需的第二部件A的硬件信息，第二部件A的软件信息需要满足第一部件升级时所需的第二部件A的软件信息，且第二部件A的固件信息需要满足第一部件升级时所需的第二部件A的固件信息，才能实现第一部件的升级。

举例来说，第一从软件版本1.0升级到软件版本2.0时，需要的第二部件的信息的匹配范围可以为：第二部件A的硬件版本为3.0，软件版本为4.0，固件版本为2.0。

在一种可能的实施方式中，第一部件升级时所需的第二部件的信息的匹配范围可以为第二部件A的软件信息和第二部件B的硬件信息。也就是说，升级第一部件时，第二部件A的软件信息需要满足第一部件升级时所需的第二部件A的软件信息，且第二部件B的硬件信息需要满足第一部件升级时所需的第二部件B的硬件信息，才能实现第一部件的升级。

举例来说，第一从软件版本1.0升级到软件版本2.0时，需要的第二部件的信息的匹配范围可以为：第二部件A的软件版本为2.0或者2.0以上，第二部件B的硬件版本为3.0或者3.0以上，第二部件B的硬件型号为除1234以外的任意型号。

在一种可能的实施方式中，第一部件升级时所需的第二部件的信息的匹配范围可以为第二部件A的固件信息和软件信息、第二部件B的硬件信息，以及第二部件C的软件信息、固件信息和硬件信息。也就是说，升级第一部件时，第二部件A的固件信息和软件信息需要分别满足第一部件升级时所需的第二部件A的固件信息和软件信息，第二部件B的硬件信息需要满足第一部件升级时所需的第二部件B的硬件信息，且第二部件C的软件信息需要满足第一部件升级时所需的第二部件C的软件信息、第二部件C的固件信息需要满足第一部件升级时所需的第二部件C的固件信息，以及第二部件C的硬件信息满足第一部件升级时所需的第二部件C的硬件信息，才能实现第一部件的升级。

举例来说，假设第一部件为MDC，当为MDC升级自动驾驶功能时，需要MDC当前的软件版本为2.0，需要MDC中传感器1的软件版本为2.0，传感器2的硬件型号为XXXX。当MDC作为第一部件时，第一部件关联的第二部件包括MDC、传感器1和传感器2，第一部件升级时所需的第二部件的信息的匹配范围为：MDC的软件信息、传感器1的软件信息，以及传感器2的硬件信息。在升级MDC时，MDC的软件信息满足于MDC的软件版本为2.0，传感器1的软件信息满足于传感器1的软件版本为2.0，且传感器2的硬件信息满足于传感器2的硬件型号为XXXX时，表明MDC关联的第二部件满足第一条件，可以实现对MDC的升级。

可以理解的，上述示例仅为举例，第一部件可以为车辆中任一部件，本申请实施例对此不作限定。

步骤S503，在第二部件满足第一条件的情况下，通过OTA升级第一部件。

可选地，在第二部件满足第一条件的情况下，可以通过OTA从OTA服务器或者CDN下载、安装并激活第一部件的升级包，从而对第一部件进行升级。

在本申请实施例中，通过在升级第一部件时，第一部件关联的第二部件的信息进行检查；在第二部件的信息满足第一部件升级时所需的第二部件的信息的匹配范围时，升级第一部件，从而降低了第一部件升级失败，以及进行第一部件升级后出现部分功能不可用、易出错等问题的可能，提高了OTA升级的可靠性，提升了用户体验。

考虑到第二部件的信息可以为硬件信息、软件信息和固件信息中的至少一项。因此，第一部件升级时所需的第二部件的信息的匹配范围中可能涉及到硬件信息、软件信息和固件信息中的一者或多者。其中，软件信息和固件信息可以通过升级第二部件进行改变，硬件信息只能通过更换第二部件的硬件进行改变。

在一种可能的实现方式中，在第二部件的信息中的软件信息和/或固件信息不满足第一条件的情况下，则可以通过升级第二部件的方式，以使第二部件满足第一条件。在满足第一条件之后，升级第一部件。

第一条件中，第一部件升级时所需的第二部件的信息的匹配范围中可以包括软件信息和/或固件信息。在第二部件的软件信息和/或固件信息不满足上述第一条件的情况下，可以升级第二部件，以使升级后的第二部件的信息满足第一部件升级时所需的第二部件的信息的匹配范围，从而使升级后的第二部件满足第一条件。之后，就可以通过OTA升级第一部件。

这样，可以保证第一部件升级时，关联的第二部件满足第一条件，从而降低升级出错的可能性，提升用户体验。同时，通过在第二部件的信息中的软件信息和/或固件信息不满足第一条件的情况下，先升级第二部件，再升级第一部件，可以提升第一部件升级成功的概率，有利于第一部件的升级。

可以理解的是，在本申请实施例中，如果升级后的第二部件的信息仍然不能满足第一部件升级时所需的第二部件的信息的匹配范围，那么无法升级第一部件。在一次或多次升级第二部件后，第二部件仍无法满足第一条件的情况下，可以通知车端升级失败，以便于用户进行排查。

在一种可能的实现方式中，在第二部件的信息中的硬件信息不满足第一条件的情况下，则通知车端升级失败。

第一条件中，第一部件升级时所需的第二部件的信息的匹配范围中可以包括硬件信息。在第二部件的硬件信息不满足上述第一条件的情况下，升级第二部件的软件是无法使第二部件满足第一条件的，需要更换第二部件的硬件才能使第二部件满足第一条件。因此，在所述第二部件的信息中的硬件信息不满足所述第一条件的情况下，可以通知车端升级失败，以便于用户更换硬件。

这样，既可以降低升级出错的可能性，又可以提示用户不能升级的原因，从而提升用户体验。

可选地，在第二部件的信息中的软件信息和/或固件信息不满足第一条件，且第二部件的信息中的硬件信息不满足第一条件的情况下，可以暂不升级第二部件，而直接通知车端升级失败，这样可以节省时间以及工作量。

图5b所示的方法可以由OTA服务器、OTA管理模块和OTA升级模块中的任意一者执行。在图5b所示的方法由OTA服务器执行的情况下，OTA服务器、OTA管理模块和OTA升级模块之间的交互流程可以参见图6。在图5b所示的方法由OTA管理模块执行的情况下，OTA服务器、OTA管理模块和OTA升级模块之间的交互流程可以参见图7。在图5b所示的方法由OTA升级模块执行的情况下，OTA服务器、OTA管理模块和OTA升级模块之间的交互流程可以参见图8。

下面结合图6对OTA服务器执行图5b所示的方法的过程进行说明。图6示出根据本申请实施例的基于OTA的升级方法的交互流程图。如图6所示，所述基于OTA的升级方法包括：

步骤S601，OTA管理模块收集车内各部件的软件信息、固件信息和硬件信息。

其中，软件信息可以包括软件版本号，固件信息可以包括固件版本号，硬件信息可以包括硬件型号和/或硬件版本号。车内的部件包括但不限于图2所示的部件。OTA管理模块可以部署在GW中(如图2所示)，也可以部署在其他部件中(未示出)，例如Tbox中，对此本申请实施例不做限制。在一个示例中，OTA管理模块可以向各部件部署的OTA升级模块发送用于收集部件的信息的消息。各部件部署的，OTA升级模块接收到收集软硬件部件的信息的消息后，可以将所在部件的软件信息、固件信息和硬件信息中的一者或多者返回至OTA管理模块。

步骤S602，OTA管理模块向OTA服务器上报各部件的软件信息、固件信息和硬件信息。

OTA管理模块确认各OTA升级模块完成信息上报后，可以将收集到的各部件的信息上报至OTA服务器。在一个示例中，OTA管理模块可以向OTA服务器发送各部件的标识，以及每个标识关联的信息。其中，部件的标识可以用于识别唯一的部件，部件的标识可以包括部件的名称、部件的编号，或者部件的地址等，对此本申请不做限制。

在一种可能的实现方式中，OTA管理模块可以在与OTA服务器建立无线通信链路的情况下或者在接收到OTA服务器发送的上报信息的指示的情况下，收集车内各部件的信息并向OTA服务器上报各部件的信息。OTA管理模块也可以周期性的收集车内各部件的信息，并在与OTA服务器建立无线通信链路的情况下或者在接收到OTA服务器发送的上报信息的指示的情况下，将当前收集到的各部件的信息上报至OTA服务器。本申请实施例中，对OTA管理模块收集各部件的信息、以及上报各部件的信息的时机不做限制。

步骤S603，OTA服务器获取第一部件对应的第一策略包。

其中，第一策略包可以用于表示第一部件对应的策略包。第一策略包可以用于指示升级第一部件。

可选地，第一策略包中包括第一条件，即升级第一部件时，第一部件关联的第二部件需要满足的条件。在实施中，第一策略包中，可以包括第一部件关联的第二部件的标识，以及所述第一条件。这样，OTA服务器可以根据第二部件的标识，从OTA管理模块上报的各部件的信息中，查找出第一部件关联的第二部件的信息。

在应用中，第一策略包还可以包括升级条件、升级类型、升级顺序、用户通知策略、升级包大小，以及升级包下载地址等。其中，升级条件可以包括：车辆不处于以下状态：紧急事件处理状态、发动机处于工作状态、存储空间不足、剩余流量低于预设流量阈值等。当车辆处于以上状态中的任一状态时，升级包下载过程容易出现下载端点等状况，进而导致升级包下载失败。升级类型可以包括：静默(无需通知用户即升级)、常规(用户同意后升级)和强制(通知用户后无需用户同意即升级)。升级顺序可以表示不同部件升级的时间先后顺序。例如，为MDC升级自动驾驶功能时，需要先升级传感器(在需要升级多个传感器的软件版本的情况下，可以同时或者按照一定的时间先后顺序依次升级各传感器)，再升级MDC。升级包的大小一般为几M到十几M。升级包下载地址可以指向OTA服务器也可以指向内容分发网络(Content Delivery Network，CDN)，也就是说，升级包可以从OTA服务器下载，可以从CDN服务器下载。

在实施中，OTA服务器可以根据升级前第一部件的软件版本信息，确定升级后第一部件的软件版本信息，并根据升级后第一部件的软件版本信息从软件仓库中获取第一部件的升级包或者第一部件的升级包的下载地址。OTA服务器可以根据升级前第一部件的软件版本信息和升级后第一部件的软件版本信息生成所述第一策略包。当然，上述第一策略包也可以由软件仓库根据升级前第一部件的软件版本信息和升级后第一部件的软件版本信息生成，OTA服务器可以从软件仓库中获取所述第一策略包。本申请实施例，对第一策略包的生成方式不做限制。

步骤S604，OTA服务器根据第一策略包中的第二部件的标识，查找第一部件关联的第二部件的信息。

第一策略包中可能包括一个或多个第二部件的标识。由于通过步骤S601和步骤S602，OTA服务器获取到了车内各部件的信息。因此，OTA服务器可以根据各第二部件的标识，在获取到的信息中，分别查找到第一部件关联的每个第二部件的信息。

在本步骤中查找的第二部件的信息可以包括软件信息、固件信息和硬件信息中的一者或多者。具体查找的信息的内容可以根据第一条件中指示的匹配范围确定。例如，第一条件中指示的第二部件A的匹配范围为软件信息和固件信息，则查找到的第二部件的信息为第二部件A的软件信息和固件信息。又如，第一条件中指示的第二部件B的匹配范围为软件信息和硬件信息，则查找到的第二部件的信息为第二部件B的软件信息和固件信息。当然，在本步骤中，可以将第二部件的软件信息、固件信息和硬件信息都找出来，并后续确定第二部件是否满足第一条件时，选择需要的信息进行匹配即可。

步骤S605，OTA服务器根据查找到的第二部件的信息确定第二部件是否满足第一条件。

其中，第一条件为在升级第一部件时，第二部件的信息满足于所述第一部件升级时所需的第二部件的信息的匹配范围。可以理解的是，第一部件关联的第二部件可以有一个或多个。针对每个第二部件，存在一个在第一部件升级时所需的该第二部件的信息的匹配范围。

针对每个第二部件：通过步骤S603，OTA服务器可以获取到第一部件升级时所需的该第二部件的信息的匹配范围(即第一条件)，通过步骤S604，OTA服务器可以获取到该第二部件的信息。基于此，在本步骤中，OTA服务器可以根据该第二部件的信息确定该第二部件是否满足第一条件。在该第二部件的信息满足于第一部件升级时所需的该第二部件的信息的匹配范围时，可以确定该第二部件满足第一条件。

可以理解的是，在所有的第二部件满足第一条件时，可以确定第一部件关联的第二部件满足第一条件。

在第一部件关联的第二部件满足第一条件的情况下，表明第一部件具备升级的条件，可以升级第一部件，此时可以执行步骤S606至步骤S608。

步骤S606，OTA服务器向OTA管理模块发送第一策略包。

步骤S607，在第一策略包指示执行第一部件的升级操作时，OTA管理模块向第一部件部署的OTA升级模块发送升级指示。

其中，升级指示用于指示OTA升级模块执行升级操作，具体为安装并激活升级包。

在一个示例中，第一策略包中包括升级条件、升级类型和升级顺序，且升级条件为发动机不处于工作状态，升级类型为静默，升级顺序为第一个升级。OTA管理模块接收到第一策略包后，对第一策略包进行解析后，若确定当前发动机不处于工作状态，则OTA管理模块可以确定当前需要执行第一部件的升级操作。此时，OTA管理模块可以向第一部件部署的OTA升级模块发送升级指示。

步骤S608，OTA升级模块接收到升级指示后，升级第一部件。

在一种可能的实现方式中，步骤S607发送的升级指示中可以包括第一部件的升级包。在步骤S608中，OTA升级模块可以在接收到升级指示后，从升级指示中获取第一部件的升级包，安装并激活第一部件的升级包，以升级第一部件。需要说明的是，这里的第一部件的升级包可以是OTA服务器在步骤606下发第一策略包时一起下发至OTA管理模块的，也可以是OTA管理模块接收到第一策略包之后，根据第一策略包中的下载地址(从OTA服务器或者CDN中)下载的。

在一种可能的实现方式中，步骤S607发送的升级指示中可以包括第一部件的升级包的下载地址。在步骤S608中，OTA升级模块可以在接收到升级指示后，从升级指示中获取第一部件的升级包的下载地址，按照该下载地址(从OTA服务器或者CDN中)下载第一部件的升级包，安装并激活第一部件的升级包，以升级第一部件。

本申请实施例通过OTA实现了第一部件的升级，本申请实施例对获取第一部件的升级包的方式不做限制。

第二部件的信息可以为硬件信息、软件信息和固件信息中的至少一项。第二部件不满足第一条件可能是由于第二部件的软件信息和/或固件信息不满足升级第一部件时需要的第二部件的软件信息和/或固件信息造成的，也可能是由于第二部件的硬件信息不满足升级第一部件时需要的第二部件的硬件信息造成的，还可能是由于第二部件的软件信息和/或固件信息，以及硬件信息，均不满足升级第一部件时需要的第二部件的软件信息和/或固件信息，以及硬件信息造成的。在软件信息和/或固件信息不满足的情况下，可以通过升级第二部件使得第二部件的软件信息和/或固件信息满足升级第一部件时需要的第二部件的软件信息和/或固件信息，进而使得第二部件满足第一条件。而在硬件信息不满足的情况下，则需要更换硬件才能升级第一部件。下面分别对上述两种情况下的交互过程进行说明。

在第二部件的信息中的软件信息和/或固件信息不满足第一条件的情况下，表明升级第二部件后，才能实现第一部件的升级，此时可以执行步骤S609至步骤S613。

步骤S609，OTA服务器获取软件信息和/或固件信息不满足第一条件的第二部件的升级包，以及第二部件对应的第二策略包。

这里，针对第一部件关联的任意一个第二部件：在第一部件升级时所需的第二部件的信息的匹配范围包括软件信息和/或固件信息，且升级第一部件时，该第二部件的软件信息和/或固件信息不满足第一条件中指示的第一部件升级时所需的该第二部件的软件信息和/或固件信息的情况下，表明该第二部件的软件信息不满足第一条件，该第二部件可以被确定为软件信息和/或固件信息不满足第一条件的第二部件。

对于软件信息和/或固件信息不满足第一条件的第二部件，需要首先升级该第二部件，以使该第二部件的软件信息和/或固件信息满足第一条件，进而使第一部件关联的第二部件满足第一条件。因此，OTA服务器可以获取软件信息和/或固件信息不满足第一条件的第二部件的升级包，以升级第二部件。

第二策略包可以用于表示第二部件对应的策略包。第二策略包可以用于指示升级第二部件。第二策略包中包括第二部件之间的升级顺序，OTA管理模块可以按照该升级顺序指示不同的第二部件进行升级。

在一种可能的实现方式中，第二策略包还可以包括第二部件关联的第三部件的标识，以及第二条件。其中，第二部件关联的第三部件可以表示升级第二部件时需要满足一定条件的部件。在本申请实施例中，升级第二部件时第三部件需要满足的条件可以称为第二条件。也就是说，在第三部件满足第二条件时，可以实现对第二部件的升级，在第三部件不满足第二条件时，无法实现对第二部件的升级。第二条件可以为升级第二部件时，第三部件的信息满足于第二部件升级时所需的第三部件的信息的匹配范围。第二条件可以参照第一条件，这里不再赘述。

在一种可能的实现方式中，第二策略包还可以包括升级条件、升级类型、升级顺序、用户通知策略、升级包大小，以及升级包下载地址等。第二策略包可以参照第一策略包这里不再赘述。

步骤S610，OTA服务器向OTA管理模块发送第一策略包、第二部件的升级包，以及第二策略包。

步骤S611，在第二策略包指示执行第二部件的升级操作时，OTA管理模块采用第二部件的升级包对软件信息和/或固件信息不满足第一条件的第二部件进行升级，以使第二部件满足第一条件。

在第二部件的软件信息和/或固件信息满足第一条件时，表明第一部件具备进行软件升级的条件，可以升级第一部件。

步骤S612，在第一策略包指示执行第一部件的升级操作时，OTA管理模块向第一部件部署的OTA升级模块发送升级指示。

步骤S613，OTA升级模块接收到升级指示后，升级第一部件。

步骤S612和步骤S613可以参照步骤S607和步骤S608，这里不再赘述。

可以理解的，在本申请实施例中，升级第二部件的过程需要在升级第一部件之前完成，以使第一部件可以顺利升级。

在第二部件的信息中的硬件信息不满足第一条件的情况下，表明需要更换硬件才能实现升级后的第一部件的功能，此时可以执行步骤S614和步骤S615，以便于用户了解情况，提升用户体验。

步骤S614，OTA服务器向OTA管理模块发送升级失败消息。

在一个示例中，升级失败消息中可以包括硬件信息不满足第一条件的第二部件的标识、当前的硬件版本号和/或硬件型号，以及需要的硬件版本号和/或硬件型号。

步骤S615，OTA管理模块接收到升级失败消息后，通知用户。

在接收到升级失败消息后，OTA管理模块可以通知用户哪个部件的硬件不符合硬件需求，该部件当前的硬件信息是什么，升级需要的硬件需求是什么。在一个示例中，通知的内容可以参照步骤S614中升级失败消息的内容。在一个示例中，OTA管理模块可以通过车载人机交互系统(例如影音系统)通知用户，还可以将通知发送至与Tbox等部件建立了通信连接的终端设备(例如手机、笔记本电脑等)。由终端设备向用户展示通知。

本申请实施例提供的基于OTA的升级方法，在升级第一部件时，对第一部件关联的第二部件的是否满足第一条件进行检查，以提升第一部件的升级包的成功安装和激活的可能性，降低了升级出错率，提高了用户体验。

同时，由OTA服务器执行对第二部件的检查可以不用修改OTA管理模块的逻辑，降低对OTA管理模块的要求。

下面结合图7对OTA管理模块执行图5b所示的方法的过程进行说明。图7示出根据本申请实施例的基于OTA的升级方法的交互流程图。如图7所示，基于OTA的升级方法包括：

步骤S701，OTA管理模块收集车内各部件的软件信息、固件信息和硬件信息。

考虑到OTA管理模块需要根据第一部件关联的第二部件的软件信息、固件信息和硬件信息中的一者或多者确定第二部件是否满足第一条件，因此，OTA管理模块需要收集车内各部件的软件信息、固件信息和硬件信息。

步骤S702，OTA管理模块向OTA服务器上报各部件的软件信息和/或固件信息。

考虑到OTA服务器获取或者生成策略包以及升级包时，需要使用部件的软件信息和/或固件信息。其中，在进行软件升级时，需要使用软件信息，在进行固件升级时需要使用固件信息。因此，这里需要OTA管理模块向OTA服务器上报各部件的软件信息和/或固件信息。考虑到，OTA服务器不需要对第二部件的硬件进行检查，因此，OTA管理模块不需要向OTA服务器上报各部件的硬件信息，以节省OTA管理模块与OTA服务器之间的通信资源以及OTA服务器的存储资源。

步骤S703，OTA服务器获取第一部件对应的第一策略包。

步骤S703可以参照步骤S603这里不再赘述。

步骤S704，OTA服务器向OTA管理模块发送第一策略包。

由于OTA服务器不执行第二部件是否满足第一条件的检查，因此，OTA服务器获取到第一策略包后，可以直接将第一策略包发送至OTA管理模块。

步骤S705，OTA管理模块根据第一策略包中的第二部件的标识，查找第一部件关联的第二部件的信息。

由于通过步骤S701，OTA管理模块收集了车内各部件的信息。因此，OTA管理模块可以根据各第二部件的标识，在收集到的信息中，分别查找到第一部件关联的各第二部件的信息。在本步骤中，查找到的第二部件的信息可以为软件信息、固件信息和硬件信息中的一者或多者。本步骤可以参照步骤S604，这里不再赘述。

步骤S706，OTA管理模块根据查找到的第二部件的信息确定第二部件是否满足第一条件。

步骤S706可以参照步骤S605，这里不再赘述。

在第一部件关联的第二部件满足第一条件的情况下，表明第一部件具备升级的条件，可以升级第一部件，此时可以执行步骤S707和步骤S708。

步骤S707，在第一策略包指示执行第一部件的升级操作时，OTA管理模块向第一部件部署的OTA升级模块发送升级指示。

步骤S708，OTA升级模块接收到升级指示后，升级第一部件。

步骤S707和步骤S708可以参照步骤S607和步骤S608，这里不再赘述。

在第二部件的信息中的软件信息和/或固件信息不满足第一条件的情况下，表明升级第二部件后，才能实现第一部件的升级，此时可以执行步骤S709至步骤S713。

步骤S709，OTA管理模块向OTA服务器发送第一请求，第一请求用于请求升级第二部件。

在一个示例中，第一请求中包括一个或多个第二部件的标识，以及每个第二部件当前的软件版本信息和需要的软件版本信息(可以从第一条件中获取)。

步骤S710，响应于第一请求，OTA服务器向OTA管理模块返回第二部件的升级包和第二部件对应的第二策略包。

OTA服务器接收到第一请求之后，可以按照每个第二部件需要的软件版本信息和当前的软件版本信息从软件仓库中获取各第二部件的升级包以及策略包。

步骤S711，在第二策略包指示执行第二部件的升级操作时，OTA管理模块采用第二部件的升级包对软件信息和/或固件信息不满足第一条件的第二部件进行升级，以使第二部件满足第一条件。

在一个示例中，OTA管理模块可以按照第二策略包指示的升级顺序，向各第二部件部署的OTA升级模块发送升级指示。部署第二部件的OTA升级模块接收到该升级指示后，可以升级第二部件。第二部件软件升级的方式可以参照第一部件软件升级的方式，这里不再赘述。

步骤S711可以参照步骤S611，这里不再赘述。

步骤S712，在第一策略包指示执行第一部件的升级操作时，OTA管理模块向第一部件部署的OTA升级模块发送升级指示。

步骤S713，OTA升级模块接收到升级指示后，升级第一部件。

步骤S712和步骤S713可以参照步骤S607和步骤S608，这里不再赘述。

在第二部件的信息中的硬件信息不满足第一条件的情况下，表明需要更换硬件才能实现升级后的第一部件的功能，此时可以执行步骤S714。

步骤S714，OTA服务器向用户发送升级失败通知。

在一个示例中，本步骤发送的升级失败通知中可以包括硬件信息不满足第一条件的第二部件的标识、当前的硬件版本号和/或硬件型号，以及需要的硬件版本号和/或硬件型号。在一个示例中，OTA管理模块可以通过车载人机交互系统(例如影音系统)通知用户，还可以将通知发送至与Tbox等部件建立了通信连接的电子设备(例如手机、笔记本电脑等)。由该电子设备向用户展示通知。

本申请实施例提供的基于OTA的升级方法，在升级第一部件时，根据第一部件关联的第二部件的信息对第二部件是否满足第一条件进行检查，以确保第一部件的升级包的成功安装和激活，降低了升级出错率，提高了用户体验。

同时，由OTA管理模块执行第二部件是否满足第一条件的检查，可以降低OTA服务器的工作量，有利于多个车辆(例如车辆组)同时进行OTA升级。

下面结合图8对OTA升级模块执行图5b所示的方法的过程进行说明。图8示出根据本申请实施例的基于OTA的升级方法的交互流程图。如图8所示，基于OTA的升级方法包括：

步骤S801，OTA管理模块收集车内各部件的软件信息和固件信息。

步骤S802，OTA管理模块向OTA服务器上报各部件的软件信息和/或固件信息。

考虑到OTA管理模块和OTA服务器均不需要对第二部件的硬件进行检查，因此，OTA管理模块不需要收集车内各部件的硬件信息，也不要向OTA服务器上报各部件的硬件信息。

步骤S803，OTA服务器获取第一部件对应的第一策略包。

步骤S803可以参照步骤S603，这里不再赘述。

步骤S804，OTA服务器向OTA管理模块发送第一策略包。

步骤S805，在第一策略包指示执行第一部件的升级操作时，OTA管理模块向第一部件部署的OTA升级模块发送升级指示以及第一策略包。

步骤S806，OTA升级模块在接收到升级指示的情况下，根据第一策略包中的第二部件的标识，获取第一部件关联的第二部件的信息。

本步骤中获取的第二部件的信息可以包括软件信息、固件信息和硬件信息中的一者或多者。

在一个示例中，OTA升级模块可以向OTA管理模块发送第二请求，其中，第二请求用于获取第二部件的软件信息、固件信息和硬件信息中的一者或多者，第二请求中包括一个或多个第二部件的标识。OTA管理模块接收到第二请求后，可以根据第二请求中包括的第二部件的标识，通过相应的OTA升级模块获取相应的第二部件的软件信息、固件信息以及硬件信息。然后，OTA管理模块可以将获取到的软件信息、固件信息和硬件信息发送至第一部件部署的OTA升级模块。在一种可能的实现方式中，OTA管理模块可以在步骤S801中除了收集各部件的软件信息和固件信息以外，还可以手机各部件的硬件信息，这样，OTA管理模块在接收到第二请求后，在本地查找第二部件的软件信息、固件信息和硬件信息，而无需再与第二部件部署的OTA升级模块进行交互，可以节省时间。

步骤S807，OTA升级模块根据获取的第二部件的信息确定第二部件是否满足第一条件。

在第一部件关联的第二部件满足第一条件的情况下，表明第一部件具备升级的条件，可以升级第一部件，此时可以执行步骤S808。

步骤S808，OTA升级模块升级第一部件。

在第二部件的信息中的软件信息和/或固件信息不满足第一条件的情况下，表明升级第二部件后，才能实现第一部件的升级，此时可以执行步骤S809至步骤S814。

步骤S809，OTA升级模块向OTA管理模块发送第一请求，其中，第一请求用于请求升级第二部件。

步骤S810，OTA管理模块向OTA服务器发送第一请求。

步骤S809和步骤S810可以参照步骤S709，这里不再赘述。

步骤S811，响应于第一请求，OTA服务器向OTA管理模块返回第二部件的升级包和第二部件对应的第二策略包。

步骤S811可以参照步骤S710，这里不再赘述。

步骤S812，在第二策略包指示执行第二部件的升级操作时，OTA管理模块采用第二部件的升级包对软件信息和/或固件信息不满足第一条件的第二部件进行升级，以使第二部件满足第一条件。

步骤S813，OTA管理模块向第一部件部署的OTA升级模块发送第二部件升级完成消息。

步骤S814，OTA升级模块接收到第二部件升级完成消息时，升级第一部件。

步骤S812和步骤S813可以参照步骤S807和步骤S808，这里不再赘述。

在第二部件的信息中的硬件信息不满足第一条件的情况下，表明需要更换硬件才能实现升级后的第一部件的功能，此时可以执行步骤S815和步骤S816。

步骤S815，OTA升级模块向OTA管理模块发送升级失败消息。

步骤S815可以参照步骤S614，这里不再赘述。

步骤S816，OTA管理模块接收到升级失败消息后，通知用户。

步骤S816可以参照步骤S615，这里不再赘述。

本申请实施例提供的基于OTA的升级方法，在升级第一部件的软件时，对第一部件关联的第二部件是否满足第一条件进行了检查，以确保第一部件的升级包的成功安装和激活，降低了升级出错率，提高了用户体验。

同时，由OTA升级模块执行第二部件是否满足第一条件的检查，可以降低OTA服务器的工作量，以及OTA管理模块的工作量，有利于车内多个部件的同步升级，特别是有利于整车升级。

需要说明的是，OTA服务器在向OTA管理模块发送策略包(例如第一策略包、第二策略包等)或者升级包(例如第一部件的升级包、第二部件的升级包等)之前，需要对策略包和升级包进行签名。OTA管理模块在接收到签名的策略包或者升级包后，先验证策略包或者升级包的签名，在签名验证通过之后，再进行后续处理。同样，OTA管理模块在向OTA升级模块发送策略包或者升级包之前，需要对策略包和升级包进行签名。OTA升级模块在接收到签名的策略包或者升级包之后，可以先验证策略包或者升级包的签名，在签名验证通过之后再进行后续处理。这样，可以提高数据安全性，降低升级出错的可能性。

图9示出根据本申请实施例的基于OTA的升级装置的结构示意图。该装置90可以设置在OTA服务器、OTA管理模块和OTA升级模块中的任意一者之中。如图9所示，该装置90可以包括：

获取模块91，用于获取与第一部件关联的第二部件的信息；确定模块92，用于根据获取模块91获取的第二部件的信息确定第二部件是否满足第一条件，第一条件为升级第一部件时，第二部件需要满足的条件；第一升级模块93，用于在确定模块92确定第二部件满足第一条件的情况下，通过OTA升级第一部件。

在一种可能的实现方式中，第一条件为在升级第一部件时，第二部件的信息满足于第一部件升级时所需的第二部件的信息的匹配范围。

在一种可能的实现方式中，第二部件的信息为硬件信息、软件信息和固件信息中的至少一项。

在一种可能的实现方式中，装置90还包括：

第二升级模块，用于在第二部件的信息中的软件信息和/或固件信息不满足第一条件的情况下，则升级第二部件以使第二部件满足第一条件。

在一种可能的实现方式中，装置90还包括：

通知模块，用于在第二部件的信息中的硬件信息不满足第一条件的情况下，则通知车端升级失败。

在本申请实施例中，通过在升级第一部件时，第一部件关联的第二部件的信息进行检查；在第二部件的信息满足第一部件升级时所需的第二部件的信息的匹配范围时，升级第一部件，从而降低了第一部件升级失败，以及进行第一部件升级后出现部分功能不可用、易出错等问题的可能，提高了OTA升级的可靠性，提升了用户体验。

本申请的实施例提供了一种电子设备，包括：处理器以及用于存储处理器可执行指令的存储器；其中，所述处理器被配置为执行所述指令时实现上述方法。

本申请的实施例提供了一种计算机程序产品，包括计算机可读代码，或者承载有计算机可读代码的非易失性计算机可读存储介质，当所述计算机可读代码在电子设备的处理器中运行时，所述电子设备中的处理器执行上述方法。

本申请的实施例提供了一种软件升级装置，包括存储器和处理器，所述存储器存储计算机程序指令，所述处理器运行所述计算机程序指令以执行上述方法。

在所述软件升级装置的第一种可能的实现方式中，所述装置还包括收发器，用于接收策略包、升级包、升级失败消息或第二部件的信息，或者用于发送升级指示、升级失败通知等中的至少一项。

上述软件升级装置可应用于包括但不限于智能网联车、机器人和智能家居等形式的终端设备。当应用于智能网联车时，所述软件升级装置可以是智能网联车本身，或者是智能网联车的一个部件，例如中央网关、车联网车端通信终端(Telematics BOX，T-box)、人机交互控制器(Human-Machine Interaction，HMI)、移动数据中心(Mobile DataController，MDC)、高级驾驶辅助系统(Advanced Driving Assistant System，ADAS)或电子控制单元(Electronic Control Unit，ECU)，又或者是上述部件内的一个子装置，还可以是除了上述部件以外智能网联车内的一个独立的装置。

本申请的实施例提供了一种软件升级装置，包括存储器和处理器，所述存储器存储计算机程序指令，所述处理器运行所述计算机程序指令以执行上述方法。

在所述软件升级装置的第一种可能的实现方式中，所述装置还包括收发器，用于接收第二部件的信息，或者用于发送升级包、策略包、升级失败消息等中的至少一项。

上述软件升级装置可应用于网络侧，例如以网络侧的一个服务器形式存在。

本申请的实施例提供了一种终端软件升级系统，包括上述可应用于终端设备的软件升级装置以及上述可应用于网络侧的软件升级装置。

本申请的实施例提供了一种计算机可读存储介质，包括计算机程序指令，当所述计算机指令在被处理器运行时，使得所述软件升级装置执行上述方法。

本申请的实施例提供了一种电子设备，该电子设备中包括处理器，处理器被配置为支持该电子设备执行上述方法中相应的功能。该电子设备还可以包括存储器，存储器用于与处理器耦合，其保存该电子设备必要的程序指令和数据。该电子设备还可以包括通信接口，用于该电子设备与其他设备或通信网络通信。

本申请的实施例提供了一种芯片系统，该芯片系统包括处理器，用于电子设备或服务器实现上述方法中所涉及的功能，例如，例如接收或处理上述方法中所涉及的数据和/或信息。在一种可能的设计中，所述芯片系统还包括存储器，所述存储器，用于保存电子设备或服务器必要的程序指令和数据。该芯片系统，可以由芯片构成，也可以包含芯片和其他分立器件。

在本申请实施例中，计算机可读存储介质可以是可以保持和存储由指令执行设备使用的指令的有形设备。计算机可读存储介质例如可以是(但不限于)电存储设备、磁存储设备、光存储设备、电磁存储设备、半导体存储设备或者上述的任意合适的组合。计算机可读存储介质的更具体的例子(非穷举的列表)包括：便携式计算机盘、硬盘、随机存取存储器(Random Access Memory，RAM)、只读存储器(Read Only Memory，ROM)、可擦式可编程只读存储器(Electrically Programmable Read-Only-Memory，EPROM或闪存)、静态随机存取存储器(Static Random-Access Memory，SRAM)、便携式压缩盘只读存储器(Compact DiscRead-Only Memory，CD-ROM)、数字多功能盘(Digital Video Disc，DVD)、记忆棒、软盘、机械编码设备、例如其上存储有指令的打孔卡或凹槽内凸起结构、以及上述的任意合适的组合。

这里所描述的计算机可读程序指令或代码可以从计算机可读存储介质下载到各个计算/处理设备，或者通过网络、例如因特网、局域网、广域网和/或无线网下载到外部计算机或外部存储设备。网络可以包括铜传输电缆、光纤传输、无线传输、路由器、防火墙、交换机、网关计算机和/或边缘服务器。每个计算/处理设备中的网络适配卡或者网络接口从网络接收计算机可读程序指令，并转发该计算机可读程序指令，以供存储在各个计算/处理设备中的计算机可读存储介质中。

用于执行本申请操作的计算机程序指令可以是汇编指令、指令集架构(Instruction Set Architecture，ISA)指令、机器指令、机器相关指令、微代码、固件指令、状态设置数据、或者以一种或多种编程语言的任意组合编写的源代码或目标代码，所述编程语言包括面向对象的编程语言—诸如Smalltalk、C++等，以及常规的过程式编程语言—诸如“C”语言或类似的编程语言。计算机可读程序指令可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络—包括局域网(Local Area Network，LAN)或广域网(WideArea Network，WAN)—连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。在一些实施例中，通过利用计算机可读程序指令的状态信息来个性化定制电子电路，例如可编程逻辑电路、现场可编程门阵列(Field-ProgrammableGate Array，FPGA)或可编程逻辑阵列(Programmable Logic Array，PLA)，该电子电路可以执行计算机可读程序指令，从而实现本申请的各个方面。

这里参照根据本申请实施例的方法、装置(系统)和计算机程序产品的流程图和/或框图描述了本申请的各个方面。应当理解，流程图和/或框图的每个方框以及流程图和/或框图中各方框的组合，都可以由计算机可读程序指令实现。

这些计算机可读程序指令可以提供给通用计算机、专用计算机或其它可编程数据处理装置的处理器，从而生产出一种机器，使得这些指令在通过计算机或其它可编程数据处理装置的处理器执行时，产生了实现流程图和/或框图中的一个或多个方框中规定的功能/动作的装置。也可以把这些计算机可读程序指令存储在计算机可读存储介质中，这些指令使得计算机、可编程数据处理装置和/或其他设备以特定方式工作，从而，存储有指令的计算机可读介质则包括一个制造品，其包括实现流程图和/或框图中的一个或多个方框中规定的功能/动作的各个方面的指令。

也可以把计算机可读程序指令加载到计算机、其它可编程数据处理装置、或其它设备上，使得在计算机、其它可编程数据处理装置或其它设备上执行一系列操作步骤，以产生计算机实现的过程，从而使得在计算机、其它可编程数据处理装置、或其它设备上执行的指令实现流程图和/或框图中的一个或多个方框中规定的功能/动作。

附图中的流程图和框图显示了根据本申请的多个实施例的装置、系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或指令的一部分，所述模块、程序段或指令的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。

也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行相应的功能或动作的硬件(例如电路或ASIC(Application SpecificIntegrated Circuit，专用集成电路))来实现，或者可以用硬件和软件的组合，如固件等来实现。

尽管在此结合各实施例对本发明进行了描述，然而，在实施所要求保护的本发明过程中，本领域技术人员通过查看所述附图、公开内容、以及所附权利要求书，可理解并实现所述公开实施例的其它变化。在权利要求中，“包括”(comprising)一词不排除其他组成部分或步骤，“一”或“一个”不排除多个的情况。单个处理器或其它单元可以实现权利要求中列举的若干项功能。相互不同的从属权利要求中记载了某些措施，但这并不表示这些措施不能组合起来产生良好的效果。

以上已经描述了本申请的各实施例，上述说明是示例性的，并非穷尽性的，并且也不限于所披露的各实施例。在不偏离所说明的各实施例的范围和精神的情况下，对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。本文中所用术语的选择，旨在最好地解释各实施例的原理、实际应用或对市场中的技术的改进，或者使本技术领域的其它普通技术人员能理解本文披露的各实施例。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。

Claims (13)

1.一种基于空中下载技术OTA的升级方法，其特征在于，所述方法包括：

获取与第一部件关联的第二部件的信息；

根据所述第二部件的信息确定所述第二部件是否满足第一条件，所述第一条件为升级所述第一部件时，所述第二部件需要满足的条件；

在所述第二部件满足所述第一条件的情况下，通过所述OTA升级所述第一部件。

2.根据权利要求1所述的方法，其特征在于，所述第一条件为在升级所述第一部件时，所述第二部件的信息满足于所述第一部件升级时所需的第二部件的信息的匹配范围。

3.根据权利要求1或2所述的方法，其特征在于，所述第二部件的信息为硬件信息、软件信息和固件信息中的至少一项。

4.根据权利要求1-3任一项所述的方法，其特征在于，所述方法还包括：

在所述第二部件的信息中的软件信息和/或固件信息不满足所述第一条件的情况下，则升级所述第二部件以使所述第二部件满足所述第一条件。

5.根据权利要求1-4任一项所述的方法，其特征在于，所述方法还包括：

在所述第二部件的信息中的硬件信息不满足所述第一条件的情况下，则通知车端升级失败。

6.一种基于空中下载技术OTA的升级装置，其特征在于，所述装置包括：

获取模块，用于获取与第一部件关联的第二部件的信息；

确定模块，用于根据所述获取模块获取的第二部件的信息确定所述第二部件是否满足第一条件，所述第一条件为升级所述第一部件时，所述第二部件需要满足的条件；

第一升级模块，用于在所述确定模块确定第二部件满足所述第一条件的情况下，通过所述OTA升级所述第一部件。

7.根据权利要求6所述的装置，其特征在于，所述第一条件为在升级所述第一部件时，所述第二部件的信息满足于所述第一部件升级时所需的第二部件的信息的匹配范围。

8.根据权利要求6或7所述的装置，其特征在于，所述第二部件的信息为硬件信息、软件信息和固件信息中的至少一项。

9.根据权利要求6-8任一项所述的装置，其特征在于，所述装置还包括：

第二升级模块，用于在所述第二部件的信息中的软件信息和/或固件信息不满足所述第一条件的情况下，升级所述第二部件以使所述第二部件满足所述第一条件。

10.根据权利要求6-9任一项所述的装置，其特征在于，所述装置还包括：

通知模块，用于在所述第二部件的信息中的硬件信息不满足所述第一条件的情况下，通知车端升级失败。

11.一种电子设备，其特征在于，包括：

处理器；

用于存储所述处理器可执行指令的存储器；

其中，所述处理器被配置为执行所述指令时实现权利要求1至5中任意一项所述的方法。

12.一种计算机可读存储介质，其上存储有计算机程序指令，其特征在于，所述计算机程序指令被处理器执行时实现权利要求1至5中任意一项所述的方法。

13.一种计算机程序产品，其特征在于，包括计算机可读代码，或者承载有计算机可读代码的非易失性计算机可读存储介质，当所述计算机可读代码在电子设备的处理器中运行时实现权利要求1至5中任意一项所述的方法。

Images