一种车辆OTA软件包的下载方法、装置、设备及介质与流程

一种车辆ota软件包的下载方法、装置、设备及介质
技术领域
1.本技术涉及车辆网络技术领域，特别地，涉及一种车辆ota软件包的下载方法、装置、设备及介质。


背景技术：

2.目前，车辆系统升级所需的软件包一般从ota管理平台下载得到，在现有技术中，关于车辆ota软件包的下载，通常是采用单一的重复下载机制，即在软件包的下载过程中，如果软件包下载失败，会持续的重复启动下载动作，这无疑会造成车辆ota软件包下载效率低下，浪费系统资源，且会影响用户的体验。基于此，如何提高车辆ota软件包的下载效率是亟待解决的技术问题。


技术实现要素：

3.本技术的目的在于提供一种车辆ota软件包的下载方法、装置、设备及介质，针对一个上电周期设计最大下载重试次数，避免下载次数过多，频繁消耗软件及平台资源，影响车辆整车使用功能。
4.本技术的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本技术的实践而习得。
5.根据本技术实施例的一个方面，提供了一种车辆ota软件包的下载方法，所述方法包括：响应于车辆的启动，检测所述车辆的本地软件包的版本信息与ota管理平台的平台软件包的版本信息是否一致；如果车辆本地的软件包版本信息与ota管理平台的软件包版本信息不一致，则从ota管理平台下载所述平台软件包；如果所述平台软件包下载失败，则从多个参考原因中确定导致所述平台软件包下载失败的目标原因；确定所述目标原因对应的下载重试次数阈值，并按照所述下载重试次数阈值，从所述ota管理平台重新下载所述平台软件包。
6.在一些实施例中，在确定所述目标原因对应的下载重试次数阈值之前，所述方法还包括：获取由ota管理平台下发的各个参考原因对应的下载重试次数阈值。
7.在一些实施例中，所述按照所述下载重试次数阈值，从所述ota管理平台重新下载所述平台软件包，包括：在历史重试次数值的基础上增加一个数值，以记录在当前的重试次数值，所述历史重试次数值为在历史上记录的从所述ota管理平台下载所述平台软件包的重试次数；判断所述重试次数值是否超过所下载重试次数阈值；如果所述重试次数值未超过所下载重试次数阈值，则从所述ota管理平台重新下载所述平台软件包；如果所述平台软件包下载失败，则返回在历史重试次数值的基础上增加一个数值的步骤。
8.在一些实施例中，所述方法还包括：如果所述重试次数值超过所下载重试次数阈值，则清零所述重试次数值，并终止软件包下载流程。
9.在一些实施例中，所述方法还包括：如果所述平台软件包下载成功，则清零所述重试次数值，并向所述ota管理平台发送软件包下载成功的反馈信号。
10.在一些实施例中，在所述目标原因为网络原因时，所述从所述ota管理平台重新下载所述平台软件包，包括：根据所述重试次数值，计算从所述ota管理平台重新下载所述平台软件包的延迟时间，其中，所述延迟时间与所述重试次数值正相关；在所述延迟时间之后，从所述ota管理平台重新下载所述平台软件包。
11.在一些实施例中，按照如下公式计算从所述ota管理平台重新下载所述平台软件包的延迟时间：
12.t＝n
×
t
13.其中，t表示所述延迟时间；n表示所述重试次数值；t表示预设时间参数。
14.根据本技术实施例的一个方面，提供了一种车辆ota软件包的下载装置，所述装置包括：版本检测单元，用于响应于车辆的启动，检测所述车辆的本地软件包的版本信息与ota管理平台的平台软件包的版本信息是否一致；下载单元，用于如果车辆本地的软件包版本信息与ota管理平台的软件包版本信息不一致，则从ota管理平台下载所述平台软件包；原因判定单元，用于如果所述平台软件包下载失败，则从多个参考原因中确定导致所述平台软件包下载失败的目标原因；重试次数确定单元，用于确定所述目标原因对应的下载重试次数阈值，并按照所述下载重试次数阈值，从所述ota管理平台重新下载所述平台软件包。
15.根据本技术实施例的一个方面，提供了一种计算机可读介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现如上述实施例中所述的车辆ota软件包的下载方法。
16.根据本技术实施例的一个方面，提供了一种电子设备，包括：一个或多个处理器；存储器，用于存储所述处理器的可执行指令，当所述可执行指令被所述一个或多个处理器执行时，使得所述一个或多个处理器实现如上述实施例中所述的车辆ota软件包的下载方法。
17.由以上本技术的技术方案，与现有技术相比，其显著的有益效果在于：本技术设计ota软件下载过程中的各种异常情况下的重试机制，应对网络不好、车辆断电、存储空间不足、版本校验失败等各种异常场景。
18.针对一个上电周期设计最大下载次数，避免下载次数过多，频繁消耗软件及平台资源，影响车辆整车使用功能。
19.应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本技术。
附图说明
20.通过参照附图详细描述其示例性实施例，本技术的上述和其它特征及优点将变得更加明显。
21.图1示出了根据本技术一个实施例的一个流程图；
22.图2示出了根据本技术一个实施例的另一个的流程图；
23.图3示出了根据本技术一个实施例的车辆ota软件包的下载装置简图；
24.图4示出了根据本技术一个实施例的电子设备的计算机系统的结构示意图。
具体实施方式
25.现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本技术将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。
26.此外，所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施例中。在下面的描述中，提供许多具体细节从而给出对本技术的实施例的充分理解。然而，本领域技术人员将意识到，可以实践本技术的技术方案而没有特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知方法、装置、实现或者操作以避免模糊本技术的各方面。
27.附图中所示的方框图仅仅是功能实体，不一定必须与物理上独立的实体相对应。即，可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。
28.附图中所示的流程图仅是示例性说明，不是必须包括所有的内容和操作/步骤，也不是必须按所描述的顺序执行。例如，有的操作/步骤还可以分解，而有的操作/步骤可以合并或部分合并，因此实际执行的顺序有可能根据实际情况改变。
29.在一些实施例中，本技术设计ota软件下载过程中的各种异常情况下的重试机制，应对网络不好、车辆断电、存储空间不足、版本校验失败等各种异常场景。针对一个上电周期设计最大下载次数，避免下载次数过多，频繁消耗软件及平台资源，影响车辆整车使用功能。
30.根据一些实施例，本技术提供了一种车辆ota软件包的下载方法，所述方法包括：
31.步骤101，响应于车辆的启动，检测所述车辆的本地软件包的版本信息与ota管理平台的平台软件包的版本信息是否一致；
32.步骤102，如果车辆本地的软件包版本信息与ota管理平台的软件包版本信息不一致，则从ota管理平台下载所述平台软件包；
33.步骤103，如果所述平台软件包下载失败，则从多个参考原因中确定导致所述平台软件包下载失败的目标原因；
34.步骤104，确定所述目标原因对应的下载重试次数阈值，并按照所述下载重试次数阈值，从所述ota管理平台重新下载所述平台软件包。
35.基于上述实施例，如图1-2所示，在步骤101中，车辆每次上电时，t-box自动向ota管理平台请求版本检测，检测车辆的本地软件包的版本信息与ota管理平台的平台软件包的版本信息是否一致。
36.在步骤102中，如果车辆本地的软件包版本信息与ota管理平台的软件包版本信息不一致时，即当车辆本地的软件包版本信息为旧版本，ota管理平台的软件包版本信息为最新版本时，则从ota管理平台下载最新版本的平台软件包。
37.在步骤103中，多个参考原因包括网络原因、存储空间不足、版本完整性校验不通过、车辆断电以及其他原因等，如果平台软件包下载失败，则从多个参考原因中确定导致平台软件包下载失败的目标原因。
38.在步骤104中，当因为目标原因下载失败时，找出目标原因下载失败后，可以重新再次下载的重试次数阈值，并根据重试次数阈值重新再次下载平台软件包，判定重新下载
的次数是否超过重试次数阈值，避免下载次数过多，频繁消耗软件及平台资源，影响车辆整车使用功能。
39.进一步的，如图2所示，(1)因网络原因造成的下载失败时。此时，对应的会将重试的时间间隔拉长，每次失败间隔递增，本设计举例一种递增方法，每失败一次，下载重试时间间隔拉长10秒。重试次数阈值包括网络原因重试次数，因网络原因引起的重试不能超过网络原因重试次数。
40.(2)因存储空间不足造成的下载失败，不进行下载重试，因此因存储空间不足的重试次数为0，t-box直接回到初始状态，本次下载结束，上报平台下载失败；t-box删除本地升级包和任务。
41.(3)因版本完整性校验不通过造成的下载失败时，不进行自动下载重试，t-box直接回到检测到新版本状态，t-box立即删除已下载的升级包，车辆可以重新触发软件包下载，触发方式包括手动触发，重试次数阈值包括完整性重试次数，重新触发的最多重试次数不能超过预先设置的完整性重试次数，完整性重试次数可以根据实际需求设定以及更改；
42.(4)因车辆断电造成的下载失败时，断电造成的下载中断，不进行下载重试，因此因车辆断电的重试次数为0，t-box直接回到下载暂停状态，待下次上电触发下载后，t-box基于断点处继续下载，即从暂停恢复下载。
43.(5)因其他原因失败造成的下载失败时，即在网络原因、存储空间不足、版本完整性校验不通过和车辆断电之外的原因导致下载失败时，按照(1)网络原因的流程进行尝试，给网络、平台、t-box本身提供一定的等待时间进行各自运行状态的改变。
44.根据一些实施例，在步骤104，确定所述目标原因对应的下载重试次数阈值之前，所述方法还包括：
45.获取由ota管理平台下发的各个参考原因对应的下载重试次数阈值。其中，在一些实施例中，下载失败的重试次数阈值的设置都可以由ota平台进行配置，ota平台可根据实际情况进行设置重试次数阈值，实现方式为通过版本检测接口下发给到uc-master；下载失败重试次数仅在车辆本次上电周期中进行累计，车辆下电则本次下载重试次数清零，下次上电重新开始计数。如果车辆下载失败重试次数耗尽，则不再进行下载重试。
46.根据一些实施例，在步骤104，所述按照所述下载重试次数阈值，从所述ota管理平台重新下载所述平台软件包，包括：
47.在历史重试次数值的基础上增加一个数值，以记录在当前的重试次数值，所述历史重试次数值为在历史上记录的从所述ota管理平台下载所述平台软件包的重试次数；判断所述重试次数值是否超过所下载重试次数阈值；如果所述重试次数值未超过所下载重试次数阈值，则从所述ota管理平台重新下载所述平台软件包；如果所述平台软件包下载失败，则返回在历史重试次数值的基础上增加一个数值的步骤。
48.基于上述实施例，如图2所示，返回在历史重试次数值的基础上增加一个数值的步骤中，如果下载失败为0次，即刚开始下载时，如果下载失败后，重试次数值为0 1，此时，历史重试次数值为0，当前的重试次数值为0 1。如果已经下载失败过1次，继续下载还是下载失败时，则重试次数值为1 1，此时，历史重试次数值为1，当前的重试次数值为1 1。
49.根据一些实施例，所述方法还包括：如果所述重试次数值超过所下载重试次数阈值，则清零所述重试次数值，并终止软件包下载流程。
50.基于上述实施例，如图2所示，当下载失败，且重试次数值超过重试次数阈值还时，则清零重试次数值，并终止软件包下载流程，等待车辆下次上电重新触发下载流程。
51.根据一些实施例，如图2所示，所述方法还包括：如果所述平台软件包下载成功，则清零所述重试次数值，并向所述ota管理平台发送软件包下载成功的反馈信号，结束本次下载流程。
52.根据一些实施例，在所述目标原因为网络原因时，所述从所述ota管理平台重新下载所述平台软件包，包括：根据所述重试次数值，计算从所述ota管理平台重新下载所述平台软件包的延迟时间，其中，所述延迟时间与所述重试次数值正相关；在所述延迟时间之后，从所述ota管理平台重新下载所述平台软件包。
53.基于上述实施例，因网络问题导致下载失败时，为保证网络能够重新连接成功，为保证系统有更多准备时间，增加了一种递增方法，每失败一次，下载重试时间间隔拉长，按照如下公式计算从所述ota管理平台重新下载所述平台软件包的延迟时间：
54.t＝n
×
t
55.其中，t表示所述延迟时间；n表示所述重试次数值；t表示预设时间参数。在一些实施例中，t设置为10秒，即网络原因的每次重试下载的时间间隔为n
×
10，保证每次重试时间间隔拉长。在另一些实施例中，延迟时间t不限于公式所述的计算方法，每次重试时间间隔可以是不规律的增长或者不增长或者减小。
56.以下为了方便本领域技术人员理解，以另一种方式重新详细说明本技术：
57.在另外的一些实施例中，如图2所示，其步骤包括：
58.1、车辆每次上电时，t-box同内部程序设置的版本检测接口向后台请求版本检测，后台下发ecu版本信息。
59.2、t-box向后台车辆ecu请求版本检测，后台下发ecu版本信息。并随通过该版本检测接口同时下发本次上电，下载失败的最大重试次数nnetworkmax、ncheckmax至t-box。其中，ncheckmax为完整性重试次数的计数器，nnetworkmax为网络原因重试次数的计数器。
60.3、开始下载，并启动最大重试次数计数器nnetwork＝0，即网络原因重试次数为0。
61.4、判断所有下载包是否均成功下载，如果均已成功下载，则返回后台下载流程结束，下载成功。若失败，则进入下一步失败原因判断。
62.5、判断下载失败原因是否为为网络状态不好，且车辆未断电。
63.若是，nnetwork计数器 1，判断此时最大重试次数计数器nnetwork是否溢出，若溢出，t-box最大重试次数计数器nnetwork清零，本次下载流程结束，不再进行重试，等待下次上电。若未溢出，则等待t＝nnetwork*10s尝试重新下载。
64.若不是，则进入下一步继续判断：
65.6、判断是否基于存储空间检测不足，造成的下载失败。
66.若是，不进行直接进行下载重试，t-box需直接回到初始状态，本次下载结束，t-box删除本地升级包和任务；上报平台下载失败，t-box可以再次向后台发起重新下载软件包请求；等待后台重新下发完整信息，并对ncheck计数器 1，判断最大重试次数计数器ncheck是否溢出，若溢出，t-box最大重试次数计数器ncheck清零，不再向后台发起重新下载软件包请求，等待下次上电循环。
67.若不是，则进入下一步继续判断：
68.7、判断是否为车辆断电。断电造成的下载中断，不进行重试，t-box直接回到下载暂停状态，待下次触发下载后，t-box基于断点处继续下载，若不是，采用5流程应对。
69.在另一些实施例中，本技术中的一些步骤也可以采用如下方法来代替：
70.下载失败的重试次数由ota平台配置的下载失败重试次数，通过版本检测接口下发给到uc-master；
71.下载失败重试次数仅在车辆本次上电周期中进行累计，车辆下电则本次下载重试次数清零，下次上电重新开始计数。如果车辆下载失败重试次数耗尽，则不再进行下载重试；
72.基于网络不好，下载超时，需要进行超时重试；重试次数为ota平台配置的下载重试次数，每次重试间隔为n*10s，n表示第几次的重试；
73.基于车辆断电情况下，造成的下载中断，不进行重试，uc-master直接回到下载暂停状态，待下次触发下载后，uc-master基于断点处继续下载；
74.基于存储空间检测不足，造成的下载失败，不进行重试，uc-master直接回到初始状态，本次下载结束，上报平台下载失败；uc-master删除本地升级包和任务；
75.基于完整性校验不通过，造成的下载失败，不进行重试，uc-master直接回到检测到新版本状态，uc-master立即删除已下载的升级包。车辆可以重新触发软件包下载；
76.基于常规模式下的下载也不需要用户同意，uc-master检测到任务后自动触发下载；
77.基于静默模式下的下载触发，需要在车辆每次上电时自动进行触发，对于一个ota任务的自动触发最大次数为6次，如果最大触发次数耗尽，则uc-master将结束本次下载，上报平台下载失败；uc-master回到初始状态，删除本地升级包和任务。
78.以下介绍本技术的装置实施例，可以用于执行本技术上述实施例中的车辆ota软件包的下载方法。
79.图3示出了本技术一个实施例中车辆ota软件包的下载装置的简图300，所述装置包括：
80.版本检测单元301，用于响应于车辆的启动，检测所述车辆的本地软件包的版本信息与ota管理平台的平台软件包的版本信息是否一致；
81.下载单元302，用于如果车辆本地的软件包版本信息与ota管理平台的软件包版本信息不一致，则从ota管理平台下载所述平台软件包；
82.原因判定单元303，用于如果所述平台软件包下载失败，则从多个参考原因中确定导致所述平台软件包下载失败的目标原因；
83.重试次数确定单元304，用于确定所述目标原因对应的下载重试次数阈值，并按照所述下载重试次数阈值，从所述ota管理平台重新下载所述平台软件包。
84.基于上述实施例，在版本检测单元301中，车辆每次上电时，t-box自动向ota管理平台请求版本检测，检测车辆的本地软件包的版本信息与ota管理平台的平台软件包的版本信息是否一致。
85.在下载单元302中，如果车辆本地的软件包版本信息与ota管理平台的软件包版本信息不一致时，即当车辆本地的软件包版本信息为旧版本，ota管理平台的软件包版本信息为最新版本时，则从ota管理平台下载最新版本的平台软件包。
86.在原因判定单元303中，多个参考原因包括网络原因、存储空间不足、版本完整性校验不通过、车辆断电以及其他原因等，如果平台软件包下载失败，则从多个参考原因中确定导致平台软件包下载失败的目标原因。
87.在重试次数确定单元304中，当因为目标原因下载失败时，找出目标原因下载失败后，可以重新再次下载的重试次数阈值，并根据重试次数阈值重新再次下载平台软件包，判定重新下载的次数是否超过重试次数阈值，避免下载次数过多，频繁消耗软件及平台资源，影响车辆整车使用功能。
88.进一步的，如图2所示，(1)因网络原因造成的下载失败时。此时，对应的会将重试的时间间隔拉长，每次失败间隔递增，本设计举例一种递增方法，每失败一次，下载重试时间间隔拉长10秒。重试次数阈值包括网络原因重试次数，因网络原因引起的重试不能超过网络原因重试次数。
89.(2)因存储空间不足造成的下载失败，不进行下载重试，因此因存储空间不足的重试次数为0，t-box直接回到初始状态，本次下载结束，上报平台下载失败；t-box删除本地升级包和任务。
90.(3)因版本完整性校验不通过造成的下载失败时，不进行自动下载重试，t-box直接回到检测到新版本状态，t-box立即删除已下载的升级包，车辆可以重新触发软件包下载，触发方式包括手动触发，重试次数阈值包括完整性重试次数，重新触发的最多重试次数不能超过预先设置的完整性重试次数，完整性重试次数可以根据实际需求设定以及更改；
91.(4)因车辆断电造成的下载失败时，断电造成的下载中断，不进行下载重试，因此因车辆断电的重试次数为0，t-box直接回到下载暂停状态，待下次上电触发下载后，t-box基于断点处继续下载，即从暂停恢复下载。
92.(5)因其他原因失败造成的下载失败时，即在网络原因、存储空间不足、版本完整性校验不通过和车辆断电之外的原因导致下载失败时，按照(1)网络原因的流程进行尝试，给网络、平台、t-box本身提供一定的等待时间进行各自运行状态的改变。
93.图4示出了适于用来实现本技术实施例的电子设备的计算机系统的结构示意图。
94.需要说明的是，图4示出的电子设备的计算机系统400仅是一个示例，不应对本技术实施例的功能和使用范围带来任何限制。
95.如图4所示，计算机系统400包括中央处理单元(central processing unit，cpu)401，其可以根据存储在只读存储器(read-only memory，rom)402中的程序或者从储存部分408加载到随机访问存储器(random access memory，ram)403中的程序而执行各种适当的动作和处理，例如执行上述实施例中所述的车辆ota软件包的下载方法。在ram403中，还存储有系统操作所需的各种程序和数据。cpu401、rom402以及ram403通过总线404彼此相连。输入/输出(input/output，i/o)接口405也连接至总线404。
96.以下部件连接至i/o接口405：包括键盘、鼠标等的输入部分406；包括诸如阴极射线管(cathode ray tube，crt)、液晶显示器(liquid crystal display，lcd)等以及扬声器等的输出部分407；包括硬盘等的储存部分408；以及包括诸如lan(local area network，局域网)卡、调制解调器等的网络接口卡的通信部分409。通信部分409经由诸如因特网的网络执行通信处理。驱动器410也根据需要连接至i/o接口405。可拆卸介质411，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器410上，以便于从其上读出的计算机程
序根据需要被安装入储存部分408。
97.特别地，根据本技术的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本技术的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分409从网络上被下载和安装，和/或从可拆卸介质411被安装。在该计算机程序被中央处理单元(cpu)401执行时，执行本技术的系统中限定的各种功能。
98.需要说明的是，本技术实施例所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(erasable programmable read only memory，eprom)、闪存、光纤、便携式紧凑磁盘只读存储器(compact disc read-only memory，cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本技术中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本技术中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、有线等等，或者上述的任意合适的组合。
99.附图中的流程图和框图，图示了按照本技术各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。其中，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。
100.描述于本技术实施例中所涉及到的单元可以通过软件的方式实现，也可以通过硬件的方式来实现，所描述的单元也可以设置在处理器中。其中，这些单元的名称在某种情况下并不构成对该单元本身的限定。
101.作为另一方面，本技术还提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。电子设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该电子设备执行上述实施例中所述的车辆ota软件包的下载方法。
102.作为另一方面，本技术还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的电子设备中所包含的；也可以是单独存在，而未装配入该电子设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该电子设备执行时，使得该电子设备实现上述实施例中所述的车辆ota软件包的下载方法。
103.应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本技术的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。
104.通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本技术实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是cd-rom，u盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、触控终端、或者网络设备等)执行上述实施例中所述的车辆ota软件包的下载方法。
105.本领域技术人员在考虑说明书及实践这里公开的实施方式后，将容易想到本技术的其它实施方案。本技术旨在涵盖本技术的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本技术的一般性原理并包括本技术未公开的本技术领域中的公知常识或惯用技术手段。
106.应当理解的是，本技术并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本技术的范围仅由所附的权利要求来限制。