车载软件更新装置的制作方法

文档序号:6596394阅读:177来源:国知局
专利名称:车载软件更新装置的制作方法
技术领域
本发明涉及通过从车辆外部下载软件而进行软件更新的车载软件更新装置。
背景技术
以往以来,在这种装置中,如下所述的技术众所周知判定将点火开关关闭的时刻是否处于预定时间带(1天中最后结束车辆的使用的时间带)的范围内,在处于预定时间带内的情况下,许可用于通过无线通信从外部服务器获取地图数据的工作单元的工作,在处于预定时间带外的情况下,禁止工作单元的工作(例如,参照专利文献1)。专利文献1 日本专利第4147946号公报

发明内容
然而,利用车辆的时间带由于用户而不同,所以在将一定的时间带设定为预定时间带的结构(例如上述的专利文献1所记载的结构)中,在为在该预定时间带频繁利用车辆的用户的情况下,具有不能执行软件的更新处理的问题。因此,本发明的目的在于提供一种能够以考虑了在不同的时间带利用车辆的用户的方式进行软件的更新的车载软件更新装置。为了达成上述目的,根据本发明的一个技术方案,能够提供一种车载软件更新装置,该车载软件更新装置通过从车辆外部下载软件而进行软件更新,其特征在于,具备存储单元,其存储过去的ACCbccessory 配件)的接通/断开状态;软件更新期间确定单元,其基于所述存储单元内的信息,以在ACC的断开期间进行软件更新的方式,确定应该进行软件更新的软件更新期间;和软件更新执行单元,其在由所述软件更新期间确定单元确定的软件更新期间内进行软件更新。根据本发明,能够提供能够以考虑了在不同的时间带利用车辆的用户的方式进行软件的更新的车载软件更新装置。


图1是表示系统1的整体结构的图,该系统应用了本发明中的车载软件更新装置 12的一个实施例。图2是表示由车载E⑶30储存的ACC的接通/断开的履历数据的一例的图。图3是表示由本实施例的车载软件更新装置12执行的主要处理的一例的流程图。图4是用于对推定ACC被断开的可能性高的最适期间的方法的几个例子进行说明的图。标号说明1 系统10:服务器
12车载软件更新装置
20通信模块
22车载天线
30车载ECU
31存储器
32辅助存储装置
34其他的E⑶
具体实施例方式下面,参照附图,进行用于实施本发明的最佳方式的说明。图1是表示应用了本发明中的车载软件更新装置12的一个实施例的系统1的整体结构。本系统1包含设置于车辆的外部的服务器10和车载软件更新装置12。服务器10如后所述,经由无线通信对车载软件更新装置12供给软件的更新数据。 服务器10也可以是各种xSP (any type of service provider :任何类型的服务提供商) 那样的提供商的形态。也可以经由任意的路径向车载软件更新装置12供给软件的更新数据,所述任意的路径包括从TSP (Telematics Service ftOvider 信息服务提供商)经由便携运营商网的路径、从TSP经由互联网以及热点的路径。车载软件更新装置12是搭载于车辆的车载装置。在本实施例中,车载软件更新装置12具备通信模块20和车载E⑶30。通信模块20经由车载天线22接受发送电波而进行与服务器10的通信。通信模块20可以是车载电话,但在本实施例中,车载电话特别优选为像便携电话那样能够以通常的使用方法拿到车辆外部的电话。车载ECU30作为硬件结构,可以具有例如CPU、储存实现后述的各种功能的程序的 ROM、储存运算结果等的能够读写的RAM、定时器、计数器、输入接口以及输出接口等。另外, 车载E⑶30具备能够改写的存储器31、硬盘驱动器那样的辅助存储装置32。存储器31是储存后述的履历数据的单元,也可以与辅助存储装置32共用。车载ECU30例如可以是车载导航系统的ECU,也可以是与服务器(中心)交换诊断信息等的诊断ECU,也可以是通过任意的E⑶实现。另外,车载E⑶30也可以设定为新的专用的E⑶。车载ECU30经由CAN (control Ier area network 控制器局域网络)等适当的总线连接有车辆内的其他的ECU34。其他的ECU34为任意的,但在这里,假设需要软件的更新的 ECU。本实施例的车载ECU30基于表示车辆的ACC(配件)的接通/断开状态的信息(ACC 信息),将车辆的ACC的接通/断开的履历数据保存于预定的存储器31。ACC的接通/断开的履历数据可以通过例如FIFO方式,仅从预定天数的数据构成。另外,ACC信息可以基于连接于自身的各种电源线(IG线、ACC线)的状态获取,也可以从其他的信息源(例如其他的E⑶、发动机开关的信号)获取。另外,当然,IG接通状态包含于ACC的接通状态。图2是表示由车载E⑶30储存的ACC的接通/断开的履历数据的一例的图。在图 2所示的例子中,储存有7天(一周)的履历数据。在图2中,横轴表示M小时的一天的时间轴。另外,粗线的区间表示ACC的接通时间持续了 30分钟以上的期间,细线的区间表示
4ACC的接通时间的持续小于30分钟的期间。这样,车载ECU30优选将表示ACC的接通时间是否持续了预定时间(在本例中为30分钟)以上的信息与该期间对应地存储。这是为了对不以驾驶车辆为目的而将ACC接通的情况、仅以短时间驾驶为目的而将ACC接通的情况与以长时间驾驶为目的而将ACC接通的情况进行区分,考虑这些情况的不同,确定后述的软件的更新定时。图3是表示由本实施例的车载软件更新装置12执行的主要处理的一例的流程图。 图3所示的处理可以在产生了软件的更新要求的情况下起动执行。在这里,更新对象软件可以为预定的软件,其种类等是任意的。典型的更新对象软件为应该进行版本更新的软件。另外,更新对象软件也可以是包含导航系统的地图数据、音乐数据那样的数据的软件。 另外,软件的更新要求可以根据来自服务器10的要求而产生,也可以通过来自用户的输入 (例如经由对话式的接口的输入)而产生。在步骤300中,在通信模块20,从服务器10获取表示软件更新所需的下载所需时间的信息。该信息可以是表示下载所需时间本身的信息,也可以是数据量那样的间接表示下载所需时间的信息。另外,该信息也可以在例如来自服务器10的软件的更新要求(或者导向)时事先向车载软件更新装置12供给。在该情况下,步骤300也可以省略。在步骤302中,在车载E⑶30中,基于ACC的接通/断开的履历数据,推定ACC被断开的可能性较高的最适期间。该最适期间为M小时以内的期间,例如从晚6点到11点的期间,但也可以为跨日的期间,如从晚11点到次日早5点。基于ACC的接通/断开的履历数据,推定ACC被断开的可能性高的最适期间的方法,根据所需要的精度、计算负荷等, 可以是多种多样的。在这里,参照图4对可以在步骤302中使用的推定方法的几个例子进行说明。作为最简单的推定方法(下面,也称为第1推定方法),可以是基于ACC的接通/ 断开的履历数据、在任何一天都提取ACC被断开了的期间的方法。例如,在图4所示的例子中,提取期间B1、B2、A1,将其中的最长的期间Al推定为ACC被断开的可能性高的最适期间。 另外,在图4所示的例子中,期间Al为跨日的期间,例如是从晚11点经过12点(右端)到次日早5点(左侧的区间)。作为其他的优选的推定方法(下面,也称为第2推定方法),可以是如下所述的方法如图4最下段所示,在ACC的接通期间持续了预定时间(在本例中为30分钟)以上的期间、ACC的接通期间小于预定时间的期间、ACC的接通期间为零的期间赋予不同的加权, 对M小时以内的各期间计算这些加权的各日的合计,在该各期间之间对合计后的加权进行比较。例如,在图4所示的例子中,在ACC的接通期间持续了预定时间(在本例中为30 分钟)以上的期间、ACC的接通期间小于预定时间的期间、ACC的接通期间为零的期间,分别赋予“1”、“0. 5”、“0”的加权。然后,在例如期间Cl,在第1天、第3天、第4天以及第5天这4天,ACC的接通期间为预定时间以上,在第6天,ACC的接通期间小于预定时间(比零大),所以加权的合计为“4. 5”。这样,对M小时以内的各期间计算加权的合计,将加权的合计最小的期间推定为ACC被断开的可能性较高的最适期间。另外,作为该第2推定方法的变形例(下面,也称为第3推定方法),也可以等间隔地固定M小时以内的各期间(例如,每1小时的M个期间),计算对各期间的同样的加权的合计,将加权的合计最小的期间推定为ACC被断开的可能性高的最适期间。在该第3推定方法的情况下,与上述的第2推定方法不同,存在如下情况在1个期间内,例如ACC的接通期间持续了预定时间(在本例中为30分钟)以上的期间和ACC的接通期间为零的期间混合存在。在该情况下,可以根据该期间(1小时)的例如ACC的接通期间持续了预定时间以上的期间所占的比例确定加权。例如,如果ACC的接通期间持续了预定时间以上的期间为40分钟,则可以将加权计算为“ 1 X 40/60”。而且,在该第3推定方法的情况下,也同样将加权的合计最小的期间(1小时的期间)或者加权的合计最小的相邻的2个以上的期间推定为ACC被断开的可能性高的最适期间。 另外,作为该第3推定方法的变形例(下面,也称为第4推定方法),也可以设定预定时间的搜索窗口,一边使搜索窗口在横轴移动,一边搜索搜索窗口内的期间( 小时以内的期间)中的上述加权的合计最小的期间。搜索窗口的移动幅度(刻度幅度),考虑计算负荷,可以设为例如30分钟左右的幅度,或者也可以依存于搜索窗口的大小而确定,在该情况下,可以为例如搜索窗口的大小的1/2程度的幅度。另外,搜索窗口的大小(期间)也可以根据在上述步骤300中获取的软件更新所需的下载所需时间确定。搜索窗口的大小也可以例如将预定的富余量加上下载所需时间而设定。在采用该第4推定方法的情况下,不需要后述的304的处理,跳到步骤308。在步骤304中,在车载E⑶30,判定在上述步骤302中导出的最适期间(ACC被断开的可能性高的最适期间)是否比在上述步骤300中获取的下载所需时间(即软件更新所必须的下载所需时间)长。在该情况下,也可以实施设为最适期间〉下载所需时间+α (富余量)的判定。在最适期间比下载所需时间长的情况下,判定为能够在该最适期间内进行软件的更新,进入步骤308,在最适期间比下载所需时间短的情况下,判定为不能在该最适期间内进行软件的更新,进入步骤306。在步骤306中,在车载ECU30,缓和/变更最适期间的确定条件等而再次搜索能够下载的时间带。例如,在上述步骤302中通过上述第1推定方法推定了最适期间的情况下, 也可以将条件缓和为例如包含加权的合计为“0. 5”的期间。在图4所示的例子中,也可以将在期间Al加上期间Α2的至少一部分的期间推定为最适期间。或者,在上述步骤302中通过上述第1推定方法推定了最适期间的情况下,也可以通过上述第4推定方法重新推定最适期间。或者,在通过上述的第1至第3推定方法设定对加权的合计的上限阈值的情况下,也可以缓和该上限阈值,推定比下载所需时间更长的最适期间。在步骤308中,在车载ECU30中,将软件更新期间设定在如上所述那样推定出的最适期间内,在检测到软件更新期间的开始时刻的到来时,开始下载处理,经由通信模块20 从服务器10下载更新软件。另外,软件更新期间不必一定从最适期间的开始时刻开始,只要处于最适期间内,也可以在最适期间的开始时刻后开始。在本步骤308中,该下载处理的开始将在该时刻ACC被断开为必须条件。另外,在该下载的执行过程中,维持通信模块20与服务器10之间的通信状态,所以通信模块20原则上不能进行其他的通信。然而,在本实施例中,如上所述,最适期间是推定为ACC被断开的可能性高的期间的期间,所以用户将ACC接通而需要进行其他的通信的事态产生的可能性低。另外,假设在软件更新过程中将ACC接通了的情况下,也可以在车载显示器(未图示)上显示例如“软件更新中。请X分钟后再次进行IG (点火开关)接通”的信息,对用户通知请稍后进行IG (点火开关)接通。在该情况下,X分钟可以基于上述步骤300中获取
6的下载所需时间与当前的途中的下载执行时间的差而计算出,另外也可以仅在X分钟为较短时间(例如5分钟)的情况下输出上述的消息,在X分钟较长的情况下将软件更新中止或者中断。在本步骤308中,也可以将从服务器10下载的更新软件暂时储存于车载E⑶30的辅助存储装置32 (在该阶段,实质实现了本申请中所说的“软件更新”),然后在点火开关变为了接通状态时,基于辅助存储装置32内的数据,执行其他的ECU34的软件的改写(更新)。或者,也可以在本步骤308中,即在ACC断开中,通过来自服务器10的数据直接将其他的E⑶34的软件更新。根据上面说明的本实施例的车载软件更新装置12,特别起到下面的优异的效果。如上所述,基于ACC的接通/断开的履历数据,推定ACC被断开的可能性高的最适期间,在该推定出的最适期间内执行软件更新,所以能够对应于可能根据用户而不同的ACC 的接通/断开的期间的倾向,实现利用了适当的时间带的软件更新。即,能够根据用户的生活节奏,将软件更新期间设定在用户不驾驶车辆的期间内,由此,能够实现正确且迅速的软件更新。上面,对本发明的优选的实施例进行了详细说明,但本发明并不限定于上述的实施例,在不脱离本发明的范围的情况下,能够对上述的实施例加以各种变形以及置换。例如,在上述的实施例中,通过无线通信从设置于车辆外部的服务器10下载软件,由此进行软件更新,但不必一定是无线通信,也可以利用例如LAN、PLC(Power Line Communication 电力线通信)那样的有线通信。例如,在混合动力车的情况下,也能够在将充电线连接于电源而充电的期间从服务器10经由PLC下载软件,由此进行软件更新,在这样的方式的软件更新中也能够应用本发明。另外,也可以将在经销商等利用的专用工具连接于车载LAN,从专用工具下载软件,由此进行软件更新,在这样的方式的软件更新中也能够应用本发明。另外,在上述的实施例中,通过分开的单元构成车载E⑶30与通信模块20,但也可以将车载E⑶30的功能组装入通信模块20。S卩,内置于通信模块20的控制装置(EOT类) 也可以实现上述的车载E⑶30的功能。另外,在上述的实施例中,基于距当前的一天(当天)过去7天的履历数据,推定 ACC被断开的可能性高的最适期间,但本发明并不限定于此。例如也可以考虑例如按每一个星期几倾向可能不同,基于星期名称与当前的一天(当天)相同的预定天数的履历数据, 推定ACC被断开的可能性高的最适期间。或者,出于同样的观点,考虑周末(星期六日或者节假日)与平时的倾向不同,在当前的一天(当天)为周末的情况下,基于周末的预定天数的履历数据,推定ACC被断开的可能性高的最适期间,在当前的一天(当天)为平时的情况下,基于平时的预定天数的履历数据,推定ACC被断开的可能性高的最适期间另外,在上述的实施例中,ACC被接通的时间越长,赋予越大的加权,但当然也可以相反地,ACC被接通的时间越长,赋予越小的加权。在该情况下,只要优先将加权较大的期间利用于软件更新即可。另外,本国际申请主张基于2009年3月31日申请的日本专利申请第2009-087419 号的优先权,在本国际申请中通过参照而引用其全部内容。
权利要求
1.一种车载软件更新装置,该车载软件更新装置通过从车辆外部下载软件而进行软件更新,其特征在于,具备存储单元,其存储过去的ACC的接通/断开状态;软件更新期间确定单元,其基于所述存储单元内的信息,以在ACC的断开期间进行软件更新的方式,确定应该进行软件更新的软件更新期间;和软件更新执行单元,其在由所述软件更新期间确定单元确定的软件更新期间内进行软件更新。
2.如权利要求1所记载的车载软件更新装置,其中从设置于车辆外部的服务器通过无线通信下载软件,由此进行软件更新。
3.如权利要求1所记载的车载软件更新装置,其中所述软件更新期间确定单元,基于存储于所述存储单元内的过去预定天数的信息,推定M小时以内的期间中ACC被断开的可能性高的最适期间,基于该推定出的期间,确定所述软件更新期间。
4.如权利要求3所记载的车载软件更新装置,其中所述软件更新期间确定单元,将在所述过去预定天数的各日的任何一天都将ACC断开的期间推定为将所述ACC断开的可能性高的最适期间。
5.如权利要求3所记载的车载软件更新装置,其中所述软件更新期间确定单元,在所述过去预定天数的各日中,对所述ACC持续接通预定时间以上的期间赋予第1加权,对所述 ACC持续接通不到预定时间的期间赋予第2加权,对所述ACC不接通的期间赋予第3加权, 对M小时以内的各期间计算该赋予的加权的各日的合计,在该各期间之间对所述合计后的加权进行比较,由此推定将所述ACC断开的可能性高的最适期间。
6.如权利要求3所记载的车载软件更新装置,其中所述过去预定天数为前一天以前的连续的7天。
7.如权利要求3所记载的车载软件更新装置,其中所述过去预定天数为星期名称与当天相同的预定天数。
全文摘要
车载软件更新装置,通过从车辆外部下载软件而进行软件更新,其特征在于,具备存储单元,其存储过去的ACC(配件)的接通/断开状态;软件更新期间确定单元,其基于所述存储单元内的信息,以在ACC的断开期间进行软件更新的方式,确定应该进行软件更新的软件更新期间;和软件更新执行单元,其在由所述软件更新期间确定单元确定的软件更新期间内进行软件更新。
文档编号G06F11/00GK102378966SQ20098015845
公开日2012年3月14日 申请日期2009年11月4日 优先权日2009年3月31日
发明者芝寿法 申请人:丰田自动车株式会社
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1