空中下载控制方法、电子设备、汽车及可读存储介质与流程

本发明涉及基于车辆的数据控制技术领域，具体而言，涉及一种空中下载控制方法、电子设备、汽车及可读存储介质。

背景技术：

随着信息技术、互联网与汽车产业的不断融合，空中下载技术(over－the－airtechnology，简称ota)逐渐应用到汽车中，用于为车载软件程序进行更新，以保障车辆安全。在实际应用过程中，ota升级过程需要整车上电。在现有技术中，ota升级容易造成不必要的电能消耗。

技术实现要素：

本申请提供一种空中下载控制方法、电子设备、汽车及可读存储介质。

为了实现上述目的，本申请实施例所提供的技术方案如下所示：

第一方面，本申请实施例提供一种空中下载控制方法，所述方法包括：监听车辆是否需要通过网络下载程序软件；在确定所述车辆需要下载所述程序软件时，控制设置在所述车辆上的预设电子器件在所述车辆下载安装所述程序软件的过程中处于关闭状态。在本实施例中，在车辆需要下载程序软件时，可以控制未整车上电时处于开启状态的电子器件由开启状态切换为关闭状态，从而改善车辆在ota升级过程中造成不必要的电能消耗的技术问题。

结合第一方面，在一些可选的实施方式中，控制设置在所述车辆上的预设电子器件在所述车辆下载安装所述程序软件的过程中处于关闭状态，包括：在所述车辆下载安装所述程序软件的过程中，控制与所述预设电子器件对应的io口关闭，以使所述io口停止向所述预设电子器件输送电能。在本实施例中，通过io口控制预设电子器件关闭，有助于通过io口确定出具体的预设电子器件的身份信息，从而精确地实现指定的电子器件的关闭操作。

结合第一方面，在一些可选的实施方式中，控制与所述预设电子器件对应的io口关闭，包括：控制所述预设电子器件中的处于开启状态的io口关闭。在本实施例中，通过将处于开启状态的io口进行关闭，可以无需对关闭状态的io口执行关闭操作，从而有助于减少执行关闭操作的io口数量。

结合第一方面，在一些可选的实施方式中，在控制设置在所述车辆上的预设电子器件在所述车辆下载安装所述程序软件的过程中处于关闭状态之前，方法还包括：确定所述车辆内不存在用户，或确定所述车辆当前下载模式为表征无人监控的预设下载模式。在本实施例中，在不存在用户或为预设下载模式时，再执行关闭操作，有助于提升车辆使用的安全性，改善因ota升级时车辆中有用户正在使用预设电子器件时突然关闭预设电子器件的技术问题。

结合第一方面，在一些可选的实施方式中，确定所述车辆内不存在用户，包括：通过设置在所述车辆上的传感组件采集得到数据信号；根据所述数据信号确定所述车辆内不存在所述用户。在本实施例中，通过传感组件采集的数据信号，有助于准确地确定出车辆内是否存在用户，从而实现车辆内是否存在用户的判断。

结合第一方面，在一些可选的实施方式中，在控制设置在所述车辆上的预设电子器件在所述车辆下载安装所述程序软件的过程中处于关闭状态之前，所述车辆的电源模式为表征休眠模式的第一模式，在控制设置在所述车辆上的预设电子器件在所述车辆下载安装所述程序软件的过程中处于关闭状态之后，所述方法还包括：控制所述车辆的电源模式由当前的第一模式切换为表征工作模式的第二模式。在本实施例中，通过在完成预设电子器件的关闭操作后，再进行整车上电，使得预设电子器件没有人工干控制其开启时，在整车上电的过程中便不会开启，从而有助于降低车辆软件升级的耗电量。

结合第一方面，在一些可选的实施方式中，在控制设置在所述车辆上的预设电子器件在所述车辆下载安装所述程序软件的过程中处于关闭状态之后，所述方法还包括：从与所述网络设备通信连接的服务器获取并安装所述程序软件。在本实施例中，在完成预设电子器件的关闭操作后，再进行程序软件的下载和安装，便能在降低车辆升级功耗的前提下完成程序软件的安装或更新。

第二方面，本申请实施例还提供一种电子设备，包括相互耦合的存储器、处理器、通信模块，所述存储器内存储计算机程序，当所述计算机程序被所述处理器执行时，使得所述电子设备执行上述的方法。

第三方面，本申请实施例还提供一种汽车，包括汽车本体及上述的电子设备。

第四方面，本申请实施例还提供一种计算机可读存储介质，所述可读存储介质中存储有计算机程序，当所述计算机程序在计算机上运行时，使得所述计算机执行上述的方法。

为使本申请的上述目的、特征和优点能更明显易懂，下文特举本申请实施例，并配合所附附图，作详细说明如下。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍。应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本申请实施例提供的汽车与服务器的通信连接示意图。

图2为本申请实施例提供的电子设备的方框示意图之一。

图3为本申请实施例提供的空中下载控制方法的流程示意图。

图4为本申请实施例提供的电子设备的方框示意图之二。

图标：10-汽车；20-电子设备；21-处理器；22-通信模块；23-存储器；24-传感组件；30-服务器。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。显然，所描述的实施例仅仅是本申请的一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。

因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。此外，术语“第一”、“第二”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

随着信息技术、互联网与汽车产业的不断融合，空中下载技术(over－the－airtechnology，简称ota)逐渐应用到汽车(比如电动汽车)中，用于为车载软件程序进行更新，以保障车辆安全。在实际应用过程中，ota升级过程需要整车上电。在现有技术中，ota升级容易造成不必要的电能消耗。

例如，申请人发现，车辆无人时，车辆在自动进行ota升级的过程中，若车辆在停车前，车灯、雨刮等处于开启状态，然后直接关闭车辆的总电源开关，以使车辆熄火停车；在停车过程中若需要进行ota升级，则需要整车上电，在整车上电后，之前处于开启状态的雨刮、车灯通常会继续开启，从而造成不必要的电能消耗。

鉴于上述问题，本申请申请人经过长期研究探索，提出以下实施例以解决上述问题。下面结合附图，对本申请实施例作详细说明。在不冲突的情况下，下述的实施例及实施例中的特征可以相互组合。

请参照图1，本申请实施例提供的车辆可以与服务器30通过网络建立通信连接，以进行数据交互。例如，车辆可以通过网络从服务器30获取需要下载或需要更新的程序软件，该程序软件包括但不限于系统程序软件、应用程序软件，可以根据实际情况进行确定。例如，程序软件可以为整个车载系统软件，也可以为车载系统软件中的一个或多个软件模块。

在本实施例中，车辆可以包括但不限于汽车10(比如电动汽车、油电混合动力汽车等)、公交车等，这里对车辆的种类不作具体限定。

可理解地，若车辆为汽车10，那么该汽车10可以通过网络与服务器30建立通信连接，以进行数据交互。比如，汽车10在需要更新系统软件时，可以从服务器30获取需要更新的软件程序，然后完成系统软件的更新。

在本实施例中，服务器30可以是但不限于集群服务器、分布式服务器、云服务器等，这里不作具体限定。另外，车辆与服务器30通信的网络包括无线网络，无线网络包括但不限于2g/3g/4g/5g网络。

请参照图2，本发明实施例还提供一种汽车10，该汽车10可以包括汽车本体及设置在汽车本体上的电子设备20(或称为车载中央控制设备)。其中，电子设备20可以执行下述的空中下载控制方法，从而改善车辆在ota升级过程中造成不必要的电能消耗的技术问题。

在本实施例中，电子设备20可以包括处理器21、通信模块22、存储器23，处理器21、通信模块22、存储器23各个元件之间直接或间接地电性连接，以实现数据的传输或交互。例如，这些元件相互之间可通过一条或多条通讯总线或信号线实现电性连接。

处理器21可以是一种集成电路芯片、电子控制单元(electroniccontrolunit，ecu)，具有信号的处理能力。上述处理器21可以是通用处理器。例如，该处理器可以是中央处理器(centralprocessingunit，cpu)、图形处理器21(graphicsprocessingunit，gpu)、网络处理器(networkprocessor，np)等；还可以是数字信号处理器(dsp)、专用集成电路(asic)、现场可编程门阵列(fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。

通信模块22用于通过网络建立车辆与服务器30之间的通信连接，并通过网络收发数据。

存储器23可以是，但不限于，随机存取存储器，只读存储器，可编程只读存储器，可擦除可编程只读存储器，电可擦除可编程只读存储器等。在本实施例中，存储器23可以用于存储电子器件的io口信息。当然，存储器23还可以用于存储程序，处理器21在接收到执行指令后，执行该程序。

其中，io口可以理解为与预设电子器件对应的输入/输出(input/output，i/o)接口。比如，io口可以为处理器21中的与预设电子器件电连接的输入/输出接口，或者为预设电子器件中的与处理器21电连接的输入/输出接口。io口信息可以包括与预设电子器件对应的输入/输出接口的接口标识，可以用于对预设电子器件进行身份识别。例如，io口信息预先与该io口对应的预设电子器件进行关联，处理器21可以获取到各个io口的io口信息，然后根据io口信息及关联关系确定出该io口对应的预设电子器件的名称、种类等身份信息，以便于基于io口信息实现预设电子器件的精确关闭控制。

可以理解的是，图2所示的结构仅为电子设备20的一种结构示意图，电子设备20还可以包括比图2所示更多或更少的组件。图2中所示的各组件可以采用硬件、软件或其组合实现。

请参照图3，本申请实施例提供一种空中下载控制方法，该方法可以应用于上述的车辆中，由车辆中的电子设备20执行或实现空中下载控制方法的各步骤。

在本实施例中，空中下载控制方法可以包括以下步骤：

步骤s210，监听车辆是否需要通过网络下载程序软件；

步骤s220，在确定车辆需要下载程序软件时，控制设置在车辆上的预设电子器件在车辆下载安装程序软件的过程中处于关闭状态。

下面将对空中下载控制方法的各步骤进行详细阐述：

步骤s210，监听车辆是否需要通过网络下载程序软件。

在本实施例中，车辆可以通过电子设备20监听自身是否需要通过网络下载程序软件。可理解地，当车辆上的车载系统软件不是最新版本或者车载系统软件中的软件模块不是最新版本时，也就意味着车辆需要下载程序软件。若车载系统软件是最新版本或者车载系统软件中的软件模块为最新版本时，通常意味着车辆不需要下载程序软件。

作为一种可选的实施方式，车辆在监听是否需要从服务器30下载程序软件的原理可以为：电子设备20上安装的车载系统软件设置有第一版本标识，服务器30存储的车载系统软件设置有第二版本标识，电子设备20可以每隔预设时长从服务器30获取服务器30上的车载系统软件的第二版本标识，并与第一标识进行判断，若第一版本标识与第二版本标识相同，则意味着当前的车辆无需下载从服务器30下载车载系统软件。若第一版本标识与第二版本标识不相同，通常意味着车辆上的车载系统软件的版本落后与服务器30上的车载系统软件的版本，此时便确定车辆需要从服务器30下载系统程序软件。其中，预设时长可以根据实际情况进行设置这里不作具体限定。

作为另一种可选的实施方式，车辆在监听是否需要从服务器30下载程序软件的原理可以为：服务器30可以预先记录与该服务器30通信的各个电子设备20的身份信息(身份信息可以是但不限于电子设备20的ip地址、安装该电子设备20的车辆的车牌号、车辆对应的车主的身份证等)。该身份信息可以与设备的ip地址关联，以便于服务器30可以根据身份信息获取到与各个电子设备20进行通信的通信地址表(通信地址表中可以电子设备20的ip地址)。当服务器30中的车载系统软件有被更新(比如，由人工上传最新版本的车载系统软件，以替换服务器30中之前版本的车载系统软件)，或车载系统软件中的至少一个软件模块有被更新，此时，服务器30可以通过通信地址表向各个电子设备20发送用于车载系统软件更新的请求报文。各电子设备20在接收该请求报文后，便可以确定车辆需要下载程序软件。若车辆没有接收到该请求报文，便可以确定车辆无需下载程序软件。

需要说明的是，车辆需要下载的程序软件可以为整个系统程序软件，也可以为系统程序软件中的至少一个软件模块。其中，需要下载的软件模块的数量可以根据实际情况进行确定，这里不作具体限定。

可理解地，对于一个软件模块而言，车辆在确定是否需要下载更新该软件模块的方式可以与上述的车辆确定是否需要下载整个系统程序软件的过程相类似。

例如，对于车载系统软件中的各个软件模块，可以携带有标识信息，该标识信息可以包括系统版本标识及模块版本标识。对于同一个应用板块升级，比如对于车载系统软件中的导航软件模块，首先，电子设备20可以从服务器30获取到服务器30上的导航软件模块的第一标识信息，第一标识信息中包括了服务器30上的车载系统软件的第一系统版本标识，及该车载系统软件中的导航软件模块的第一模块版本标识。另外，电子设备20可以获取自身安装的导航软件模块的第二标识信息，第二标识信息中包括了电子设备20上的车载系统软件的第二系统版本标识及其导航软件模块(这里的导航软件模块指电子设备20上的车载系统软件中的导航软件模块)的第二模块版本标识。然后，电子设备20可以判断第一系统版本标识与第二系统版本标识是否相同。

若第一系统版本标识与第二系统版本标识不相同，也就意味着车辆需要从服务器30下载整个车载系统软件。

若第一系统版本标识与第二系统版本标识相同，且第一模块版本标识与第二模块版本标识不相同，通常意味着导航软件模块在服务器30上的版本与在电子设备20上的版本不相同，且服务器30上的导航软件版本优先于电子设备20上的导航软件。此时，车辆便需要从服务器30下载导航软件模块，以更新车辆上的导航软件模块，而无需从服务器30下载整个车载系统软件。基于此，可以节省下载流量，快速实现车载系统软件的更新。

若第一系统版本标识与第二系统版本标识相同，且第一模块版本标识与第二模块版本标识也相同，此时，便确定车辆无需下载程序软件。

在本实施例中，车辆处于停车状态时，车辆上的电子设备20通常处于待机状态。此时，车辆上的部分电子器件会继续运行，部分电子器件会停止运行。运行的电子器件通常为电子设备20的后台器件，例如可以为处理器21，比如，处理器21可以在电子设备20待机时监听车辆是否需要更新程序软件、监听系统日志等。在待机状态下，停止运行的电子器件可以包括车灯、雨刮、车载空调、车载音箱等。

可理解地，在待机状态下，车辆的电源模式为表征休眠模式的第一模式。在车辆使用时，车辆的电源模式为表征工作模式的第二模式。其中，第一模式与第二模式可以根据实际情况进行区分设置，这里不作具体限定。

步骤s220，在确定车辆需要下载程序软件时，控制设置在车辆上的预设电子器件在车辆下载安装程序软件的过程中处于关闭状态。

在本实施例中，当车辆通过电子设备20确定出需要下载程序软件时，电子设备20中的处理器21可以控制预设电子器件在车辆下载安装程序软件的过程中处于关闭状态。也就是在ota升级过程中，处理器21可以控制预设电子器件处于关闭状态。

其中，预设电子器件可以为车辆在整车上电后非必须开启的电子器件，可以为根据实际情况确定。比如，车辆在整车上电后，雨刮、车灯、车载空调、车载音箱等电子器件可以不用开启，这些雨刮、车灯、车载空调、车载音箱等电子器件便为非必须开启的电子器件。

可理解地，因为在确定出车辆需要下载安装程序时(可理解为在确定出车辆需要进行ota升级时)，车辆需要整车上电。在现有技术中，若在升级之前，车辆属于异常熄火(异常熄火可理解为车辆在停车时，车灯、雨刮等处于开启状态，然后直接关闭车辆的总电源开关，以使车辆熄火停车)，当车辆再次整车上电时(比如在进行ota升级时，需要整车上电)，车灯、雨刮等会继续工作，从而造成不必要的电能消耗。另外，在现有技术中，当车辆停车后，车主通常也就不需要使用该车辆，此时，车主通常远离于车辆，若此时进行ota升级，在上述的情况下，车灯、雨刮便会开启，从而造成车未被使用而车灯、雨刮却开启的异常工作状况。

基于上述设计，因为在ota升级过程中，处理器21可以控制预设电子器件处于关闭状态，所以在升级过程中，车辆上的预设电子器件(比如雨刮、车灯、车载空调、车载音箱等)便会处于关闭状态。若在升级之前，车辆为上述的异常熄火，便能关闭相应的预设电子器件运行，从而改善因升级需要整车上电而使得预设电子器件运行导致的电能消耗的技术问题，解决上述的异常工作状况。

作为一种可选的实施方式，步骤s220可以包括：在车辆下载安装程序软件的过程中，控制与预设电子器件对应的io口关闭，以使io口停止向预设电子器件输送电能。

在本实施例中，处理器21可以控制与各个预设电子器件连接的io口的通断状态，导通状态可以包括开启状态及关闭状态。若io口处于开启状态，在车辆整车上电时，通过该io口连接的电子器件便会开始工作。若io口处于关闭状态，在车辆整车上电时，通过该io口连接的电子器件便不会工作。

例如，预设电子器件为雨刮，处理器21可以控制与雨刮连接的io口的通断状态。若控制与雨刮连接的io口处于关闭状态，那么该雨刮便不会工作，若控制与雨刮连接的io口处于开启状态，该雨刮便会工作。

可理解地，不同的预设电子器件对应有不同的io口信息，处理器21可以根据io口信息控制需要关闭的电子器件的通断状态处于关闭状态，避免处理器21关闭掉必须处于开启状态的电子器件(比如通信模块22，当然也可以是其他模块器件)而影响电子设备20正常运行，从而有助于实现精确控制预设电子器件的关闭。

作为一种可选的实施方式，控制与预设电子器件对应的io口关闭，可以包括：控制预设电子器件中的处于开启状态的io口关闭。

在本实施例中，车辆上的预设电子器件的数量至少为一个。在预设电子器件为多个时，在确定出需要进行ota升级时，处理器21可以控制所有的预设电子器件的io口处于关闭状态；或者可以是控制多个预设电子器件中处于开启状态的io口关闭，而对于关闭状态的io口无需执行io口关闭的操作。

其中，处理器21可以控制所有的预设电子器件的io口处于关闭状态，可以理解为：处理器21无需检测各个预设电子器件的io口的通断状态，处理器21可以将所有预设电子器件中的处于开启状态及关闭状态的io口执行关闭操作，以使所有预设电子器件与处理器21连接的io口均处于关闭状态。基于此，处理器21可以无需检测io口的通断状态，便能快速对io口执行关闭操作。

处理器21控制多个预设电子器件中处于开启状态的io口关闭，可以理解为：处理器21先检测所有预设电子器件中与处理器21连接的io口的通断状态，然后将每个预设电子器件与处理器21连接的每个io口中的处于开启状态的io口执行关闭操作，而对于所有预设电子器件与处理器21连接的所有io口中的处于关闭状态的io口无需执行关闭操作。基于此，可以无需对处于关闭状态的io口重复地进行关闭，可以减少关闭操作的量。

在本实施例中，若车辆内存在用户，在预设电子器件不需要被开启时，可以由用户手动关闭，或者可以通过上述的方法实现预设电子器件的关闭操作。

作为一种可选的实施方式，在步骤s220之前，方法还可以包括：确定车辆内不存在用户，或确定车辆当前下载模式为表征无人监控的预设下载模式。

在本实施例中，在确定出车辆需要进行ota升级时，车辆可以判断该车辆内是否存在用户，或者车辆可以检测判断车辆当前的下载模式，然后基于判断结果决定控制策略。其中，控制策略可以根据实际情况进行设置。例如，若判断结果表征车辆内不存在用户，或表征车辆当前的下载模式为表征无人监控的预设下载模式(可以称为第一下载模式)，则控制策略便为继续执行步骤s220，以完成对预设电子器件的关闭操作。基于此，可以改善车辆在用户使用的过程中关闭需要运行的电子器件。

比如，车辆在夜间行驶的过程中且需要进行ota升级时，部分车灯通常处于开启状态(开启状态的车灯即为正在发光的车灯)，在进行ota升级时，便会继续维持当前车辆的各个预设电子器件的工作状态，需要运行的预设电子器件也就无需被关闭，即发光的车灯也就无需被关闭。

若判断结果表征车辆内存在用户，或车辆当前的下载模式为表征有人监控的第二下载模式，则控制策略可以为由用户来决定是否对预设电子器件执行关闭操作。比如可以由用户手动打开或关闭预设电子器件，或者由用户手动接受或拒绝表征继续执行步骤s220的操作提示，以使电子设备20继续或终止执行步骤s220的操作。

请参照图4，在本实施例中，确定车辆内不存在用户，可以包括：通过设置在车辆上的传感组件24采集得到数据信号；根据数据信号确定车辆内不存在用户。

在本实施例中，传感组件24包括但不限于摄像头、红外传感器、压力传感器等，处理器21可以通过传感组件24采集的数据信号判断车辆内是否存在用户。用户可以包括车辆的车主、车辆上的其他乘客中的至少一种。

例如，设置的摄像头与处理器21电连接，处理器21可以获取到摄像头采集的图像，可以通过摄像头采集车辆内的图像(即数据信号)，然后对图像进行人物识别，若确定出图像中存在人员，则确定车辆内存在用户。其中，摄像头设置在车辆内的位置及摄像头的数量可以根据实际情况进行设置，只要当车辆内实际存在用户，且通过摄像头能采集到用户并识别出图像中存在用户即可。

又例如，若传感组件24为压力传感器，可以在车辆的各个座椅上设置与处理器21连接的压力传感器。处理器21可以基于压力传感器采集的数据信号来确定座椅上是否坐有人员，从而确定车辆内是否存在用户。比如，处理器21可以根据压力传感器采集的压力值来判断座椅上是否坐有人员，当存在至少一个压力传感器采集的压力值大于或等于预设阈值时，便确定车辆内存在用户，其中，预设阈值可以根据实际情况进行设置，这里不作具体限定。

可选地，若由红外传感器来检测车内是否存在用户。比如，红外传感器为与处理器21电连接的热释电红外传感器，热释电红外传感器可以设置在车辆内，以采集车辆内各物体的红外线的波长。处理器21可以基于热释电红外传感器采集的红外线的波长来确定车辆内是否存在用户。例如，当存在波长在与人体对应的预设波长范围内时，便确定车辆内存在用户。其中，预设波长范围可以根据实际情况进行设置，这里不作具体限定。

在本实施例中，若在确定出需要进行ota升级之前，车辆的电源模式为表征休眠模式的第一模式。处理器21在控制预设电子器件处于关闭之前，可以控制车辆整车上电，也就是控制车辆的电源模式由第一模式切换为表征工作模式的第二模式。或者，处理器21在控制预设电子器件处于关闭之后，控制车辆的电源模式由第一模式切换为第二模式。

作为一种可选的实施方式，在步骤s220之后，控制车辆的电源模式由当前的第一模式切换为表征工作模式的第二模式。

可理解地，本实施例通过在控制预设电子器件处于关闭之后，在进行整车上电，那么预设电子器件在车辆上电后便不会运行。若在控制预设电子器件处于关闭之前，就进行整车上电，再控制预设电子器件关闭，此时，预设电子器件会先运行后在关闭。

在本实施例中，方法还可以包括：从与网络设备通信连接的服务器30获取并安装程序软件。

可理解地，在执行完步骤s220之后，电子设备20便从服务器30下载并安装程序软件，以完成系统程序的更新。

本发明实施例还提供一种空中下载控制装置。该空中下载控制装置可以包括至少一个可以软件或固件(firmware)的形式存储于存储器23中或固化在电子设备20操作系统(operatingsystem，os)中的软件功能模块。处理器21用于执行存储器23中存储的可执行模块，例如空中下载控制装置所包括的软件功能模块及计算机程序等。

在本实施例中，空中下载控制装置可以应用于上述的车辆中，用于执行或实现上述的空中下载控制方法，能够改善现有技术中车辆在ota升级过程中造成的不必要的电能消耗的问题。

在本实施例中，空中下载控制装置可以包括监听单元及控制关闭单元。

监听单元，用于监听车辆是否需要通过网络下载程序软件。

控制关闭单元，用于在确定车辆需要下载程序软件时，控制设置在车辆上的预设电子器件在车辆下载安装程序软件的过程中处于关闭状态。

需要说明的是，所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的空中下载控制装置的具体工作过程，可以参考前述方法中的各步骤对应过程，在此不再过多赘述。

本申请实施例还提供一种计算机可读存储介质。可读存储介质中存储有计算机程序，当计算机程序在计算机上运行时，使得计算机执行如上述实施例中的空中下载控制方法。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本申请可以通过硬件实现，也可以借助软件加必要的通用硬件平台的方式来实现，基于这样的理解，本申请的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是cd-rom，u盘，移动硬盘等)中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施场景所述的方法。

综上所述，本申请提供一种空中下载控制方法、电子设备、汽车及可读存储介质。方法包括：监听车辆是否需要通过网络下载程序软件；在确定车辆需要下载程序软件时，控制设置在车辆上的预设电子器件在车辆下载安装程序软件的过程中处于关闭状态。在本方案中，在车辆需要下载程序软件时，可以控制未整车上电时处于开启状态的电子器件由开启状态切换为关闭状态，从而改善车辆在ota升级过程中造成不必要的电能消耗的技术问题。

在本申请所提供的实施例中，应该理解到，所揭露的装置、系统和方法，也可以通过其它的方式实现。以上所描述的装置、系统和方法实施例仅仅是示意性的，例如，附图中的流程图和框图显示了根据本申请的多个实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现方式中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。另外，在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。

可以替换的，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(dsl))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，dvd)、或者半导体介质(例如固态硬盘solidstatedisk(ssd))等。

以上所述仅为本申请的优选实施例而已，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。