本发明涉及汽车控制技术领域,更具体地说,涉及一种汽车软件升级方法。
背景技术:
现有技术中的汽车,通常不支持对汽车软件进行在线升级,而需要用户将汽车开到服务点或接入专用的升级模块来进行软件升级。这种方式耗时耗力,升级效率较低。
此外,就升级时间的选择来说,如果在汽车电量不足以满足后续出行需求的时候来升级汽车软件,几乎必然导致升级失败,而在软件升级失败的情况下,又会对用户的驾车体验带来不良影响,甚至造成安全隐患。
技术实现要素:
本发明的目的在于提供一种汽车软件升级方法,其能够找到最佳时间来进行汽车软件的升级,而不会影响用户的行程。
为实现上述目的,本发明提供一种技术方案如下:
一种汽车软件升级方法,包括:a)、在第一时间段从服务器下载汽车软件升级所需的更新包;b)、在第二时间段利用更新包来对汽车软件进行升级;其中,第一时间段至少部分地基于汽车与服务器之间的通信状态来确定,第二时间段至少部分地基于汽车的电量信息和用户的驾驶信息来确定。
优选地,电量信息包括:汽车的当前电量;汽车的电量消耗速率。
优选地,驾驶信息包括:用户的用车时间偏好;用户的用车计划;以及用户的驾驶行为偏好。
优选地,用车计划基于如下项来确定:用户的日程;用户出行的行程;以及,用户所参加会议的会议纪要。
优选地,用车时间偏好及驾驶行为偏好基于用户的驾驶行为的历史数据来确定。
优选地,第二时间段由服务器来确定。
优选地,在步骤b)中,升级至少包括:第一升级阶段,基于更新包在第三时间段升级汽车软件的第一部分;以及第二升级阶段,基于更新包在第四时间段升级汽车软件的第二部分;其中,第三时间段和第四时间段均处于第二时间段内且彼此不重叠。
优选地,第三时间段和第四时间段由服务器基于对汽车所处的外界环境的监测来确定。
本发明还提供一种汽车软件升级系统,包括:更新包下载单元,用于至少部分地基于汽车与服务器之间的通信状态来确定第一时间段,并在第一时间段期间从服务器下载汽车软件升级所需的更新包;软件升级单元,与更新包下载单元耦合,用于至少部分地基于汽车的电量信息和用户的驾驶信息来确定第二时间段,并在第二时间段期间利用更新包来对汽车软件进行升级。
本发明实施例所提供的汽车软件升级方法及系统,将汽车自身电量信息、用户驾驶信息等因素考虑在内,由云端服务器来综合规划软件升级时间,能够确保用户的实际行程、潜在行程在最大程度上不受影响。此外,该方法有利于促进节省电量、不产生安全隐患,给用户的用车体验带来显著的提升。
附图说明
图1示出本发明第一实施例提供的汽车软件升级方法的流程示意图。
图2示出本发明第二实施例提供的汽车软件升级方法的流程示意图。
具体实施方式
在以下描述中提出具体细节,以便提供对本发明的透彻理解。然而,本领域的技术人员将清楚地知道,即使没有这些具体细节也可实施本发明的实施例。在本发明中,可进行具体的数字引用,例如“第一元件”、“第二装置”等。但是,具体数字引用不应当被理解为必须服从于其字面顺序,而是应被理解为“第一元件”与“第二元件”不同。
本发明所提出的具体细节只是示范性的,具体细节可以变化,但仍然落入本发明的精神和范围之内。术语“耦合”定义为表示直接连接到组件或者经由另一个组件而间接连接到组件。
以下通过参照附图来描述适于实现本发明的方法或系统的优选实施例。虽然各实施例是针对方法步骤或系统元件的单个组合来描述,但是应理解,本发明包括所公开步骤或元件的所有可能组合。因此,如果一个实施例包括步骤或元件a、b和c,而第二实施例包括步骤或元件b和d,则本发明也应被认为包括步骤或元件a、b、c或d的其他剩余组合,即使没有明确公开。
如图1所示,本发明第一实施例提供一种汽车软件升级方法,其包括如下步骤。
步骤s10、在第一时间段从服务器下载汽车软件升级所需的更新包。
具体来说,在汽车(作为优选,电动汽车)与服务器之间可以采用无线通信连接,包括基于wifi和基于移动通信的通信连接方式。在通信连接持续畅通的情况下,将更新包从服务器端传输到汽车端。
其中,第一时间段至少部分地基于汽车与服务器之间的通信状态来确定。作为示例,若移动通信信号较好,则可启动(第一时间段的起始)更新包的传输;若通信信号较差,则停止或暂停更新包的传输,以等待信号恢复到较佳状态再继续进行,直到传输整个更新包(第一时间段的结束)。
步骤s12、在第二时间段利用更新包来对汽车软件进行升级。
其中,第二时间段至少部分地基于汽车的电量信息和用户的驾驶信息来确定。
具体地,电量信息包括:汽车的当前电量和汽车的电量消耗速率。通过当前电量和电量消耗速率由汽车端向服务器端的上报,结合更新包安装到软件操作系统上所需的时间,服务器能够预测出进行软件升级所需的电量以及升级完成后汽车的剩余电量。如果用户随后有行程安排,这些剩余电量应确保用户的行程不会因电量不足而受到延误。即,仅在电量充足的情况下,才会提取更新包进行软件升级。通常来说,在软件升级前,汽车的当前电量应不低于总电量的40%,但这只是示例,并不以此为限。
根据第一实施例,用户的驾驶信息包括用户的用车时间偏好,用户的用车计划,以及,用户的驾驶行为偏好。
就用车时间偏好来说,作为示例,普通用户一般会在晚上18:00-20:00下班回家,此后,电动汽车将停放于停车库内,直到第二天早上7:00,用户再驾车上班。即,在20:00至第二天7:00这一时间段,用户倾向于不使用汽车。而对特定用户而言,其可能在用车时间偏好上不同于普通用户,例如,其更喜欢在20:00-23:00使用汽车,而在10:00-13:00不使用汽车。而为了确保普通用户、特定用户的行程都不会受到影响,汽车软件升级应避开甚至远离用户偏好的用车时间段,以确保在使用电动汽车时,汽车仍有足够的电量。
用户的用车计划基于如下一项或多项来确定:用户的日程(或日历);用户出行的行程;以及,用户所参加会议的会议纪要。对商务用户而言,其日程、行程及会议纪要往往会被电子地存储,进而,若这些信息被上传到设置于云端的服务器,云端服务器可以对商务用户的汽车软件升级时间段作出合理的规划。
“驾驶行为偏好”可以体现为用户长期养成的开车习惯,例如,急加速或平缓加速,对车载空调的使用与否及调节幅度,用户对不同路线的选择等。可以理解,驾驶行为偏好不仅能够对用户的用车时间偏好作出修正,还能够影响关于剩余电量的计算。为对驾驶行为偏好进行量化,作为示例,可以统计在某个时间段内汽车处于加速状态的时长与处于减速状态的时长之比,车载空调的调节幅度等信息,以便对用户的驾驶行为偏好进行完整的综合的量化。
优选情况下,用车时间偏好及驾驶行为偏好都是基于用户的驾驶行为的历史数据来确定。为保存历史数据,云端服务器持续监测用户的驾驶行为,将其量化并保存于云端。
基于上述各种用户驾驶信息,设置于云端的服务器可以针对每一辆电动汽车,分别确定相应的第二时间段,来进行汽车软件的升级。由于针对每一用户都能够获取其独特的“驾驶信息”,由云端服务器确定的第二时间段能够充分地体现用户对软件升级时间的偏好,从而使得软件升级在最大程度上不会影响用户的实际行程或潜在行程。
作为对上述第一实施例的进一步改进,若汽车软件升级失败,可以对汽车软件的升级过程进行自主检测,以确定升级失败的原因,并上报至服务器;随后,服务器可启动维修检测流程,以确定是软件更新包存在问题还是用户汽车自身的问题,或是因软件之间的不兼容而造成升级失败。此外,服务器可进一步建议用户更改其日程或行程。作为备选,还可以选择进行局部升级,将出现问题的部分略过(提交服务器作后续分析),而仅进行正常部分的升级。
如图2所示,本发明第二实施例提供一种改进的汽车软件升级方法,其包括如下三个步骤。
步骤s20、在第一时间段内,从云端服务器下载汽车软件升级所需的更新包。
步骤s22、在第一升级阶段,基于更新包在第三时间段升级汽车软件的第一部分。
步骤s24、在第二升级阶段,基于更新包在第四时间段升级汽车软件的第二部分。
在该第二实施例中,第三时间段和第四时间段均处于第二时间段内、且彼此不重叠。
上述第二实施例作为对第一实施例的改进,其采用了“局部升级”的方式来确保:在用户的实际或潜在行程与长时间的软件升级过程存在冲突或不可调和时,优先保证用户行程对电动汽车电量的需求,而同时,尽可能地将软件的更新部分提供予用户。
作为示例,所下载的更新包中包含了对变速箱控制程序的更新和交互操作界面的更新,在第三时间段(例如,用户出行前),仅仅进行第一部分升级,将变速箱控制程序升级到最新版本,这有利于提高电动汽车的安全性;在第四时间段(用户行程完成后),再进行第二部分升级,将电动汽车上的交互操作界面更新到最新模式。虽然第三时间段与第四时间段可以重叠或相邻,但是可以理解,第三时间段与第四时间段彼此不重叠是本发明的更优选的实施方式。作为另一示例,在第二时间段内的两个或多个不同的时间段,分别地对汽车软件的涉及行驶安全的软件部分和不涉及行驶安全的软件部分进行升级。对涉及行驶安全的软件部分的升级可优先进行。
作为进一步的改进,第三时间段和第四时间段由服务器基于对汽车所处的外界环境的监测来确定。
优选情况下,外界环境可以包括地理环境及交通状况。地理环境能够反映用户汽车所处地域、温度环境、湿度环境。举例来说,当汽车处于城市内时,即使在软件升级失败导致车辆故障的情况下(虽然这种情形极少出现),用户汽车也能够得到快速的维修;而当用户汽车处于沙漠中时,其不可能得到快速维修。根据上述第二实施例,这时,云端服务器会作出将第三时间段及第四时间段全部延后的处理。此外,不同的温度环境、湿度环境也能够对电动汽车的电量消耗速率产生显著的影响。
另一方面,“交通状况”表征当前道路是否拥堵、停车场是否存在空位等信息,在选择软件升级时间时,有必要将这些因素考虑在内。
鉴于此,云端服务器可以通过定位系统来获知电动汽车所处的地理环境、通过城市交通监测系统来获知交通状况,进而,更合理地对汽车软件升级时间进行综合规划。
通过这种综合规划,使得汽车软件升级几乎不会失败,甚至能够在用户感觉不到升级过程的情形下(但是用户知晓升级信息)完成对软件的升级,用户的用车体验将获得显著的提升。
在本发明的一些实施例中,服务器可采用通信网络所连接的一组分布式计算装置来实现,或,基于“云”来实现。在这种系统中,多个计算装置共同操作,以通过使用其共享资源来提供服务。
基于“云”的实现可提供一个或多个优点,包括:开放性、灵活性和可扩展性、可中心管理、可靠性、可缩放性、对计算资源所优化、具有聚合和分析跨多个用户的信息的能力、跨多个地理区域进行连接、以及将多个移动或数据网络运营商用于网络连通性的能力。
根据本发明另一实施例,提供一种汽车软件升级系统,该系统包括更新包下载单元和软件升级单元。
具体来说,更新包下载单元用于至少部分地基于汽车与服务器之间的通信状态来确定第一时间段,随后,在第一时间段期间更新包下载单元从服务器下载汽车软件升级所需的更新包。
软件升级单元与更新包下载单元耦合,其用于至少部分地基于汽车的电量信息和用户的驾驶信息来确定第二时间段(而非由云端服务器来确定),随后,在第二时间段期间软件升级单元直接利用所下载的更新包来对汽车软件进行升级。其中,电量信息包括汽车的当前电量和汽车的电量消耗速率,用户的驾驶信息可包括用户的用车时间偏好、用车计划,以及,(可选的)驾驶行为偏好。用车时间偏好和用车计划可记录于汽车本地端,驾驶行为偏好可从云端服务器获取。
更优选地,软件升级单元对汽车软件的升级可以分时进行,例如,在第二时间段内的第三时间段期间,先升级涉及行驶安全的第一软件部分,在随后的第二时间段内的第四时间段期间,再升级不涉及行驶安全的第二软件部分。
根据本发明另一实施例,提供一种计算机存储介质,其上存储有一批计算机可执行指令,这些计算机可执行指令在由处理器执行时,将能够实现上述第一实施例或第二实施例所提供的各种方法。
根据本发明又一实施例,提供一种控制器,该控制器在执行储存于与其耦合的存储器中的可执行指令时,将会执行第一实施例或第二实施例所提供的方法的各个步骤。
上述说明仅针对于本发明的优选实施例,并不在于限制本发明的保护范围。本领域技术人员可能作出各种变形设计,而不脱离本发明的思想及附随的权利要求。