一种车辆系统的升级方法、装置、介质及设备与流程

1.本技术涉及车辆系统升级技术领域，特别地，涉及一种车辆系统的升级方法、装置、介质及设备。


背景技术：

2.传统的车辆在下载升级软件时，车辆在各种不适合软件升级的状态下进行软件升级时，则会引起部分车辆功能无法使用或者车辆系统升级失败的情况发生，导致用户体验差，甚至可能还会出现安全风险。


技术实现要素：

3.本技术的目的在于提供一种车辆系统的升级方法、装置、介质及设备，以使得整体提高了车辆升级软件时的稳定性及安全性。
4.本技术的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本技术的实践而习得。
5.根据本技术实施例的一个方面，提供了一种车辆系统的升级方法，所述方法包括：获取ota软件包，所述ota软件包作为所述车辆系统的升级数据；获取设定车辆状态，所述设定车辆状态为满足所述车辆系统升级条件的车辆状态；采集车辆状态数据，如果所述车辆状态数据符合所述设定车辆状态，则基于所述ota软件包升级车辆系统。
6.在一些实施例中，所述采集车辆状态数据，包括：触发检测周期，在所述检测周期内，至少一次采集车辆的实际状态数据，得到至少一组实际状态数据，将所述至少一组实际状态数据作为所述车辆状态数据。
7.在一些实施例中，所述触发检测周期，在所述检测周期内，至少一次采集车辆的实际状态数据，包括：触发检测周期；响应于检测周期的触发，启动计时器，所述计时器用于记录检测时间；采集车辆的实际状态数据，并检测所述实际状态数据是否符合所述设定车辆状态；如果所述实际状态数据符合所述设定车辆状态，则判断所述检测时间是否超过所述检测周期；
8.如果所述检测时间未超过所述检测周期，则在预设间隔时间之后，返回采集车辆的实际状态数据的步骤，直至所述检测时间超过所述检测周期。
9.在一些实施例中，所述方法还包括：如果所述检测时间超过所述检测周期，则确定所述车辆状态数据符合所述设定车辆状态。
10.在一些实施例中，所述方法还包括：如果所述实际状态数据不符合所述设定车辆状态，则触发一个新的检测周期。
11.在一些实施例中，在触发一个新的检测周期之前，所述方法还包括：判断所述检测周期的触发次数是否超过触发次数阈值；如果所述检测周期的触发次数超过触发次数阈值，则终止针对所述车辆系统的升级动作；如果所述检测周期的触发次数未超过触发次数阈值，则触发一个新的检测周期。
12.在一些实施例中，所述车辆状态包括手刹状态，档位状态，车速状态，电源模式状态，充电状态，蓄电池电量状态，蓄电池电压状态，发动机转速状态，以及电机转速状态中的至少一种。
13.根据本技术实施例的一个方面，提供了一种车辆系统的升级装置，包括：所述装置包括：第一获取模块，用于获取ota软件包，所述ota软件包作为所述车辆系统的升级数据；第二获取模块，用于获取设定车辆状态，所述设定车辆状态为满足所述车辆系统升级条件的车辆状态；采集模块，用于采集车辆状态数据，如果所述车辆状态数据符合所述设定车辆状态，则基于所述ota软件包升级车辆系统。
14.根据本技术实施例的一个方面，提供了一种计算机可读介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现如上述实施例中所述的车辆系统的升级方法。
15.根据本技术实施例的一个方面，提供了一种电子设备，包括：一个或多个处理器；存储器，用于存储所述处理器的可执行指令，当所述可执行指令被所述一个或多个处理器执行时，使得所述一个或多个处理器实现如上述实施例中所述的车辆系统的升级方法。
16.由以上本技术的技术方案，与现有技术相比，其显著的有益效果在于：在车辆进行升级前对车辆状态条件的检测，可以避免车辆在例如行驶过程、溜车或其他不适合升级状态进行软件升级，从而能够避免部分车辆功能无法使用，导致用户体验差甚至出现安全风险的问题发生，进而从整体上提高了车辆升级软件时的稳定性及安全性。
17.应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本技术。
附图说明
18.通过参照附图详细描述其示例性实施例，本技术的上述和其它特征及优点将变得更加明显。
19.图1示出了根据本技术一个实施例的流程图；
20.图2示出了根据本技术一个实施例的整体流程图；
21.图3示出了根据本技术一个实施例的车辆系统的升级装置简图；
22.图4示出了根据本技术一个实施例的电子设备的计算机系统的结构示意图；
具体实施方式
23.现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本技术将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。
24.此外，所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施例中。在下面的描述中，提供许多具体细节从而给出对本技术的实施例的充分理解。然而，本领域技术人员将意识到，可以实践本技术的技术方案而没有特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知方法、装置、实现或者操作以避免模糊本技术的各方面。
25.附图中所示的方框图仅仅是功能实体，不一定必须与物理上独立的实体相对应。即，可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现
这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。
26.附图中所示的流程图仅是示例性说明，不是必须包括所有的内容和操作/步骤，也不是必须按所描述的顺序执行。例如，有的操作/步骤还可以分解，而有的操作/步骤可以合并或部分合并，因此实际执行的顺序有可能根据实际情况改变。
27.以下对本技术实施例的技术方案的实现细节进行详细阐述：
28.首先，需要说明的是，本技术中所提出的车辆系统的升级方案可以应用于车辆在工作时，对车辆系统的软件进行升级。因车辆处于工作状态，车辆的工作状态可能会影响到软件的升级，软件的升级也可能会影响到车辆的工作，为避免车辆的工作状态和车辆的软件升级之间的相互影响，本技术设置了设定车辆状态，当车辆的工作状态符合设定车辆状态时，则说明车辆的工作状态和车辆的软件升级是不会相互影响的，此时可以对车辆的软件进行升级。当车辆的工作状态不符合设定车辆状态时，则不允许车辆的软件升级，并返回给平台以及车机显示不符合设定车辆状态。本技术可以避免车辆在例如行驶过程、溜车或其他不适合升级状态进行软件升级，从而能够避免部分车辆功能无法使用，导致用户体验差甚至出现安全风险的问题发生，进而从整体上提高了车辆升级软件时的稳定性及安全性。
29.为了使本领域技术人员更好的理解本技术，下面将结合图1对本技术进行简单说明。
30.参见图1，根据一些实施例，本技术提供了一种车辆系统的升级方法，所述方法包括：
31.步骤101，获取ota软件包，所述ota软件包作为所述车辆系统的升级数据；
32.步骤102，获取设定车辆状态，所述设定车辆状态为满足所述车辆系统升级条件的车辆状态；
33.步骤103，采集车辆状态数据，如果所述车辆状态数据符合所述设定车辆状态，则基于所述ota软件包升级车辆系统。
34.基于上述实施例，如图1所示，在步骤101中，车辆通过t-box向ota平台获取需要升级的软件包，在一些实施例中，车辆每次上电时，t-box会自动向ota管理平台请求ota软件包版本检测，检测车辆的本地软件包的版本信息与ota管理平台的平台软件包的版本信息是否一致。如果一致时，则不需要升级。如果车辆本地的软件包版本信息与ota管理平台的软件包版本信息不一致时，即当车辆本地的软件包版本信息为旧版本，ota管理平台的软件包版本信息为最新版本时，则从ota管理平台下载最新版本的平台软件包。
35.继续参照图1，在步骤102中，从ota管理平台获取最新版本的同时，也获取设定车辆状态，设定车辆状态为满足所述车辆系统升级条件的车辆状态，即如果车辆满足设定车辆状态时，则可以进行升级ota软件包，如果车辆不满足设定车辆状态时，则不允许车辆升级。其中，车辆状态可以根据实际需求由ota管理平台来设定。
36.继续参照图1，为检测车辆是否满足升级所需的状态，在步骤103中，采集车辆状态数据，并检测车辆状态数据是否符合设定车辆状态。其中，车辆t-box通过实车can总线或其他类型通信方式，获取实车对应的车辆状态数据。
37.进一步的，车辆状态包括手刹状态，档位状态，车速状态，电源模式状态，充电状态，蓄电池电量状态，蓄电池电压状态，发动机转速状态，以及电机转速状态中的至少一种。
由平台根据车型选定，并设定好数据。
38.车辆状态数据和ota管理平台设置的设定车辆状态一致时，则说明车辆ota软件包的升级和车辆实际状态不会相互影响。以避免出现车辆ota软件包升级时影响到车辆状态，或者车辆状态影响到车辆ota软件包的升级，可以开始升级车辆ota软件包。
39.根据如图1所示步骤103的一些实施例中，所述采集车辆状态数据，可以按照如下步骤1031执行：
40.步骤1031，触发检测周期，在所述检测周期内，至少一次采集车辆的实际状态数据，得到至少一组实际状态数据，将所述至少一组实际状态数据作为所述车辆状态数据。
41.基于上述实施例，在一个检测周期内，可以采集多次车辆的实际状态数据，也可以只采集一次车辆的实际状态数据，一次可以采集一种或者多种车辆状态，如一次可以采集手刹状态、档位状态、车速状态、电源模式状态、充电状态、蓄电池电量状态、蓄电池电压状态、发动机转速状态以及电机转速状态中的一种或者多种。
42.将采集到的车辆的实际状态数据作为上述所说的车辆状态数据。用于将车辆状态数据与设定车辆状态做对比，若车辆状态数据和ota管理平台设置的设定车辆状态一致时，则可以开始升级软件包。
43.其中，一个检测周期的时间可以根据实际需求设定，一个周期采集的次数也可以根据实际需求设定。
44.根据一些实施例，在步骤1031，所述触发检测周期，在所述检测周期内，至少一次采集车辆的实际状态数据，包括：
45.步骤10311，触发检测周期；
46.步骤10312，响应于检测周期的触发，启动计时器，所述计时器用于记录检测时间；
47.步骤10313，采集车辆的实际状态数据，并检测所述实际状态数据是否符合所述设定车辆状态；
48.步骤10314，如果所述实际状态数据符合所述设定车辆状态，则判断所述检测时间是否超过所述检测周期；
49.步骤10315，如果所述检测时间未超过所述检测周期，则在预设间隔时间之后，返回采集车辆的实际状态数据的步骤，直至所述检测时间超过所述检测周期。
50.基于上述实施例，如图2所示，触发检测周期后，启动计时器，在计时器的检测周期内采集车辆的实际状态数据，并检测实际状态数据是否符合所述设定车辆状态，如果实际状态数据符合设定车辆状态，则判断计时器是否已经超过检测周期的时间，如果还没有超过时间，计时继续，在预设间隔时间之后，重新返回继续采集车辆的实际状态数据，直至时间超过检测周期的时间，且每一次采集的实际状态数据符合设定车辆状态时，则可以开始升级车辆ota软件包。
51.上述所说的在一个检测周期内进行多次采集车辆的实际状态数据来对比设定车辆状态的意义在于：确认车辆的实际状态数据能够长时间稳定在满足升级软件的条件下，再进行升级，保证升级软件不被打断，以及防止升级软件和车辆的实际状态相互有影响。
52.如果车辆在一个检测周期内有时候实际状态数据符合设定车辆状态，有时候实际状态数据不符合设定车辆状态时，会影响车辆升级软件不稳定，则不能允许车辆执行升级软件的动作，并返回给平台以及车机显示不符合设定车辆状态。整体提高了车辆的稳定性。
两次采集之间设置预设间隔时间，保证系统有充分的重新整理及反应时间。
53.进一步的，检测周期和预设间隔时间可以根据实际需求设定，如一个周期设定为60秒，预设间隔时间设置为500毫秒，一个检测周期的时间
÷
一个周期采集的次数＝采集一次的时间。
54.根据一些实施例，所述方法还包括：
55.步骤10316，如果所述检测时间超过所述检测周期，则确定所述车辆状态数据符合所述设定车辆状态。
56.基于上述实施例，如果检测时间超过检测周期后，且每一次采集的实际状态数据都符合设定车辆状态时，则确定车辆状态数据符合设定车辆状态，此时可以开始升级车辆ota软件包。其中，车辆状态数据包括每一次采集的实际状态数据。
57.根据一些实施例，在步骤10314中，所述方法还包括：
58.如果所述实际状态数据不符合所述设定车辆状态，则触发一个新的检测周期。
59.基于上述实施例，如图2所示，如果一个检测周期内有一次实际状态数据不符合设定车辆状态时，就重新触发一个新的检测周期，重新开始计时。因为如果一个检测周期内出现过一次实际状态数据不符合设定车辆状态时，说明车辆的实际状态数据存在不确定性，不稳定性，可能会导致影响到车辆升级软件，所以需要重新找一个车辆的实际状态数据稳定的时间段来进行升级软件。如此执行才可以提高车辆软件升级的稳定性。
60.根据一些实施例，在步骤10314，触发一个新的检测周期之前，所述方法还包括：
61.步骤111，判断所述检测周期的触发次数是否超过触发次数阈值；
62.步骤112，如果所述检测周期的触发次数超过触发次数阈值，则终止针对所述车辆系统的升级动作；
63.步骤113，如果所述检测周期的触发次数未超过触发次数阈值，则触发一个新的检测周期。
64.基于上述实施例，触发次数阈值可以根据实际需求设定，在一些实施例种，触发次数阈值设定为5次。
65.即如果一个检测周期内有一次实际状态数据不符合设定车辆状态时，就重新触发一个新的检测周期，重新开始计时。其中，重新开始一个检测周期的次数如果超过触发次数阈值，则终止车辆系统的升级动作，避免不断地重复开启新的检测周期，影响车辆的稳定性。
66.为了使本领域技术人员更清晰的理解本技术车辆系统升级方案中的设定车辆状态，以下将结合图2和表1通过一些实施例进行说明。
67.[0068][0069]
表1
[0070]
安装软件包需要判断的安装条件支持ota管理平台自定义配置；可配置的范围如下：
[0071]
1)手刹状态。
[0072]
目标状态设定为：拉起。
[0073]
设置选项：不检测or检测。设定检测时，手刹拉起为符合设定的状态。
[0074]
2)档位状态。
[0075]
目标状态设定为：p档orn档。
[0076]
设置选项：不检测or检测。设定检测时：若设定检测p档，则车辆为p档时符合设定的状态；若设定检测n档，则车辆为n档时符合设定的状态。
[0077]
3)车速状态。
[0078]
目标状态设定为：车速＜xkm/h。其中，x值通过平台配置下发，根据esc选型不同，存在差异，默认值为0。
[0079]
设置选项：不检测or检测。设定检测时，车速＜xkm/h符合设定的状态。
[0080]
4)电源模式状态。
[0081]
目标状态：kl15on
[0082]
设置选项：不检测or检测。设定检测时，电源档位＝kl15on符合设定的状态。
[0083]
5)充电状态。
[0084]
目标状态：非充电状态
[0085]
设置选项：不检测or检测。设定检测时，车辆为非充电状态时符合设定的状态。
[0086]
6)蓄电池电量状态。
[0087]
目标状态：蓄电池电量在某一区间值范围内。其中，区间值范围通过平台配置下发，根据实车暗电流差异，该值存在差异。
[0088]
设置选项：不检测or检测。设定检测时，蓄电池电量在平台设置的目标范围内时符合设定的状态。
[0089]
7)蓄电池电压状态。
[0090]
目标状态：蓄电池电压在某一区间值范围内。其中，区间值范围通过平台配置下发，根据实车暗电流差异，该值存在差异。
[0091]
设置选项：不检测or检测。设定检测时，蓄电池电压在平台设置的目标范围内时符合设定的状态。
[0092]
8)发动机转速状态。
[0093]
目标状态：转速≤y。其中，y值通过平台配置下发，根据动力系统选型不同，存在差异，默认值为0。
[0094]
设置选项：不检测or检测：转速≤y。设定检测时，转速在平台设置的目标转速时符合设定的状态。
[0095]
9)电机转速状态(选项：不检测/转速为0)。
[0096]
目标状态：转速≤z。其中，z值通过平台配置下发，根据电机系统选型不同，存在差异，默认值为0。
[0097]
设置选项：不检测or检测：转速≤z。设定检测时，转速在平台设置的目标转速时符合设定的状态。
[0098]
以下将根据表1和图2进一步阐述：
[0099]
由于燃油车、新能源车包括电机等选型不同，整车达到预设时间的时长可能不同，因此，平台可支持对车辆判断循环次数nmax和每次周期性判断时长tmax进行配置。其中，判断循环次数nmax为触发次数阈值，判断时长tmax为检测周期。
[0100]
t-box端对应的配置计数器n和计时器t，且该计数器n和计时器t的有效时间为：车辆触发判断车辆条件周期内。该周期为车辆触发判断车辆条件的触发条件满足到车辆下电。
[0101]
车辆触发判断车辆条件的触发条件为：
[0102]
(1)车辆上电；
[0103]
(2)收到平台版本下发。
[0104]
以下详细步骤说明，如图2所示。
[0105]
1、在车辆触发判断车辆条件周期内即一个上电周期内，进行本判断流程。车辆上电，设置计时器t＝0，计数器n＝0。
[0106]
2、安装软件包的安装条件及最大判断次数(nmax)和时长(tmax)在版本下发时，通过ota任务一起下发给到t-box。安装软件包需要判断的安装条件支持ota管理平台自定义配置，ota平台生成配置范围管理表，如表1所示。
[0107]
3、t-box解析ota任务包，获得需要判断的车辆状态；
[0108]
4、对应车辆的实际状态通过整车can总线或其他类型通信方式给到t-box；开启计时器t＝0，计时器t开始计时。
[0109]
5、t-box以固定周期如每500ms读取一次车辆状态进行判断，获取的车辆状态是否均需满足预设条件，即逐条将实际状态与预设条件对比，是否全为都符合。其中，预设条件为平台设置的设定车辆状态。
[0110]
6、若是，t-box累计周期性获取以及判断车辆状态时间t，该t值是否大于等于tmax(平台可配置，比如60s)，即tmax时间内每次获取的车辆状态均需满足预设条件，方可判断为安装ota软件包需要的车辆条件满足；
[0111]
7、若不是，则重置计时器t＝0，最多不超过nmax次数(平台可配置，如5次)，超过次数则本次不安装，待下次条件满足再安装。
[0112]
以下介绍本技术的装置实施例，可以用于执行本技术上述实施例中的车辆系统的升级方法。对于本技术装置实施例中未披露的细节，请参照本技术上述的车辆控制方法的实施例。
[0113]
图3示出了本技术一个实施例中车辆系统的升级装置的简图300，所述装置包括：
[0114]
第一获取模块301，用于获取ota软件包，所述ota软件包作为所述车辆系统的升级数据；
[0115]
第二获取模块302，用于获取设定车辆状态，所述设定车辆状态为满足所述车辆系统升级条件的车辆状态；
[0116]
采集模块303，用于采集车辆状态数据，如果所述车辆状态数据符合所述设定车辆状态，则基于所述ota软件包升级车辆系统。
[0117]
基于上述实施例，在第一获取模块301中，车辆通过t-box向ota平台获取需要升级的软件包，在一些实施例中，车辆每次上电时，t-box会自动向ota管理平台请求ota软件包版本检测，检测车辆的本地软件包的版本信息与ota管理平台的平台软件包的版本信息是否一致。如果一致时，则不需要升级。如果车辆本地的软件包版本信息与ota管理平台的软件包版本信息不一致时，即当车辆本地的软件包版本信息为旧版本，ota管理平台的软件包版本信息为最新版本时，则从ota管理平台下载最新版本的平台软件包。
[0118]
在第二获取模块302中，从ota管理平台获取最新版本的同时，也获取设定车辆状态，设定车辆状态为满足所述车辆系统升级条件的车辆状态，即如果车辆满足设定车辆状态时，则可以进行升级ota软件包，如果车辆不满足设定车辆状态时，则不允许车辆升级。其中，车辆状态可以根据实际需求由ota管理平台来设定。
[0119]
为检测车辆是否满足升级所需的状态，在采集模块303中，采集车辆状态数据，并检测车辆状态数据是否符合设定车辆状态。其中，车辆t-box通过实车can总线或其他类型通信方式，获取实车对应的车辆状态数据。
[0120]
进一步的，车辆状态包括手刹状态，档位状态，车速状态，电源模式状态，充电状态，蓄电池电量状态，蓄电池电压状态，发动机转速状态，以及电机转速状态中的至少一种。由平台根据车型选定，并设定好数据。
[0121]
车辆状态数据和ota管理平台设置的设定车辆状态一致时，则说明车辆ota软件包的升级和车辆实际状态不会相互影响。以避免出现车辆ota软件包升级时影响到车辆状态，或者车辆状态影响到车辆ota软件包的升级，可以开始升级车辆ota软件包。
[0122]
图4示出了适于用来实现本技术实施例的电子设备的计算机系统的结构示意图。
[0123]
需要说明的是，图4示出的电子设备的计算机系统400仅是一个示例，不应对本技术实施例的功能和使用范围带来任何限制。
[0124]
如图4所示，计算机系统400包括中央处理单元(central processing unit，cpu)401，其可以根据存储在只读存储器(read-only memory，rom)402中的程序或者从储存部分408加载到随机访问存储器(random access memory，ram)403中的程序而执行各种适当的动作和处理，例如执行上述实施例中所述的车辆系统的升级方法。在ram403中，还存储有系统操作所需的各种程序和数据。cpu401、rom402以及ram403通过总线404彼此相连。输入/输出(input/output，i/o)接口405也连接至总线404。
[0125]
以下部件连接至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。
[0126]
特别地，根据本技术的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本技术的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分409从网络上被下载和安装，和/或从可拆卸介质411被安装。在该计算机程序被中央处理单元(cpu)401执行时，执行本技术的系统中限定的各种功能。
[0127]
需要说明的是，本技术实施例所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(erasable programmable read only memory，eprom)、闪存、光纤、便携式紧凑磁盘只读存储器(compact disc read-only memory，cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本技术中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本技术中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、有线等等，或者上述的任意合适的组合。
[0128]
附图中的流程图和框图，图示了按照本技术各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。其中，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。
[0129]
描述于本技术实施例中所涉及到的单元可以通过软件的方式实现，也可以通过硬件的方式来实现，所描述的单元也可以设置在处理器中。其中，这些单元的名称在某种情况下并不构成对该单元本身的限定。
[0130]
作为另一方面，本技术还提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。电子
设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该电子设备执行上述实施例中所述的车辆系统的升级方法。
[0131]
作为另一方面，本技术还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的电子设备中所包含的；也可以是单独存在，而未装配入该电子设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该电子设备执行时，使得该电子设备实现上述实施例中所述的车辆系统的升级方法。
[0132]
应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本技术的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。
[0133]
通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本技术实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是cd-rom，u盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、触控终端、或者网络设备等)执行上述实施例中所述的车辆系统的升级方法。
[0134]
本领域技术人员在考虑说明书及实践这里公开的实施方式后，将容易想到本技术的其它实施方案。本技术旨在涵盖本技术的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本技术的一般性原理并包括本技术未公开的本技术领域中的公知常识或惯用技术手段。
[0135]
应当理解的是，本技术并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本技术的范围仅由所附的权利要求来限制。