JP2011053954A

JP2011053954A - ソフトウェア更新装置

Info

Publication number: JP2011053954A
Application number: JP2009202809A
Authority: JP
Inventors: Yasunori Miyajima; 靖典宮島
Original assignee: Toyota Motor Corp
Current assignee: Toyota Motor Corp
Priority date: 2009-09-02
Filing date: 2009-09-02
Publication date: 2011-03-17
Anticipated expiration: 2029-09-02
Also published as: JP5267390B2

Abstract

【課題】ソフトウェア更新処理を行う時間帯の妥当性を利用者に判断させることができるソフトウェア更新装置を提供する。
【解決手段】車両３と通信可能に構成され、ユーザが車両３を使用しない空き時間帯に車両３のプログラム３３を更新するソフトウェア更新装置であって、プログラム３３の更新可能な空き時間帯を予測するスケジュール候補決定部１３と、予測された空き時間帯をユーザに報知するスケジュール候補提示部１４と、報知された空き時間帯の中から所定の空き時間帯を指定するユーザの操作を入力し、ユーザにより指定された空き時間帯でプログラム３３の更新を行うリプログラム処理部１５と、を備え、スケジュール候補提示部１４は、空き時間帯をユーザに報知する際に、当該空き時間における車両３の予測される位置情報をあわせて報知することを特徴として構成する。
【選択図】図１

Description

本発明は、ソフトウェア更新装置に関するものである。

従来、ソフトウェアの更新を行う装置として、ソフトウェアの更新対象である対象装置が使用されていない時間にソフトウェアの更新を行うものが知られている（例えば、特許文献１参照）。特許文献１記載の装置は、対象装置の稼動状況に基づいて対象装置の空き時間帯を決定し、空き時間帯にソフトウェアの更新を行うものである。

特開２００４−３８６１６号公報

ところで、特許文献１記載のソフトウェア更新装置にあっては、稼動状況に基づいて受信装置の空き時間を決定するため、ソフトウェア更新装置側で決定された空き時間帯と実際の空き時間帯とが一致しているという保障は無い。このため、ソフトウェア更新装置側で決定した空き時間帯に受信装置が使用されることがある。

このような問題に対して、受信装置の利用者に候補となる空き時間帯を幾つか提示し、利用者により選択された空き時間帯にソフトウェアの更新を行うことが考えられる。しかしながら、利用者にとっては、候補となる空き時間帯を単に提示されただけでは本当に空き時間帯となるか否かの判断をすることが困難である。

そこで、本発明はこのような技術課題を解決するためになされたものであって、ソフトウェア更新処理を行う時間帯の妥当性を利用者に判断させることができるソフトウェア更新装置を提供することを目的とする。

すなわち、本発明に係るソフトウェア更新装置は、移動体と通信可能に構成され、利用者が前記移動体を使用しない空き時間帯に前記移動体のソフトウェアを更新するソフトウェア更新装置であって、前記ソフトウェアの更新可能な前記空き時間帯を予測する予測手段と、前記予測手段により予測された前記空き時間帯を前記利用者に報知する報知手段と、前記報知手段により報知された前記空き時間帯の中から所定の空き時間帯を指定する前記利用者の操作を入力する入力手段と、前記利用者により指定された前記空き時間帯で前記ソフトウェアの更新を行う更新手段と、を備え、前記報知手段は、前記空き時間帯を前記利用者に報知する際に、当該空き時間における前記移動体の予測される位置情報をあわせて報知することを特徴として構成される。

本発明に係るソフトウェア更新装置では、報知手段により、予測された空き時間帯と当該予測空き時間帯における予測された位置情報とが利用者に報知される。このため、利用者に対して、報知された位置情報に基づいて、報知された空き時間帯の妥当性を検証させることができる。よって、ソフトウェア更新処理を行う時間帯の妥当性を利用者に判断させることが可能となる。

ここで、前記予測手段は、前記移動体の稼動情報に基づいて前記ソフトウェアの更新可能な前記空き時間帯を予測してもよい。このように構成することで、稼動情報に基づいて移動体を使用しない可能性の高い空き時間帯を予測することができる。

また、前記予測手段は、前記ソフトウェアの更新に要する時間に基づいて前記ソフトウェアの更新可能な前記空き時間帯を予測することが好適である。このように構成することで、ソフトウェアの更新に要する時間を考慮して、空き時間帯においてソフトウェアの更新が可能であるか否かを判定することができるので、ソフトウェアの更新が可能な空き時間帯を予測することが可能となる。

本発明によれば、ソフトウェア更新処理を行う時間帯の妥当性を利用者に判断させることができる。

実施形態に係るソフトウェア更新装置を含むソフトウェア更新システムの構成を示す概要図である。図１のソフトウェア更新システムの構成を示すブロック図である。図１に示すソフトウェア更新装置の動作を示すフローチャートである。図１に示す車両のプログラムの更新に関する情報を示す表である。図１に示す車両の使用状況を示す表である。

以下、添付図面を参照して本発明の実施形態について説明する。なお、各図において同一又は相当部分には同一の符号を付し、重複する説明を省略する。

本実施形態に係るソフトウェア更新装置は、例えば車両のプログラムのリモート更新（リプログラミング）に好適に採用されるものである。

最初に、本実施形態に係るソフトウェア更新装置を備えるソフトウェア更新システムについて説明する。図１は、実施形態に係るソフトウェア更新装置１を有するソフトウェア更新システムの構成を示す概要図である。図１に示すソフトウェア更新システムは、互いに通信可能な車両（移動体）３及びサーバ２を備えている。車両３は、更新可能なプログラム（ソフトウェア）を有しており、車両３のプログラムは、サーバ２が有するリプログラミングデータ１２に基づいて、通信を介して更新可能に構成されている。

図２を用いて、ソフトウェア更新システムの構成について詳細に説明する。図２は、図１のソフトウェア更新システムの構成を示すブロック図である。図２に示すように、サーバ２は、車両３のプログラムを更新するソフトウェア更新装置１を備えている。このソフトウェア更新装置１は、使用状況学習ＤＢ１０、プログラム更新情報１１、リプログラミングデータ１２、スケジュール候補決定部（予測手段）１３、スケジュール候補提示部（報知手段）１４及びリプログラム処理部（更新手段）１５を備えている。

使用状況学習ＤＢ１０は、車両３の使用状況が格納・蓄積されるデータベースである。使用状況学習ＤＢ１０は、例えば、車両３から送信された使用状況を格納する機能を有している。使用状況としては、例えば、車両位置、移動経路、使用回数、使用時間等が用いられる。使用状況を把握する方法として、例えば、時間帯に対応する使用回数及び車両位置が曜日ごとに格納された表が用いられる。車両位置は、例えば、自宅車庫、勤務先駐車場、他駐車場等、停止の目的をユーザが判断しやすいように区分されたものを用いてもよい。この表には、例えば過去数週間分の実績データが蓄積される。また、使用状況を把握する方法として、例えば、日に対応する使用回数が曜日、週ごとに格納された表が用いられてもよい。この表には、例えば、数ヶ月分の実績データが蓄積される。

プログラム更新情報１１は、プログラムの更新に関する情報である。プログラム更新情報１１として、例えば、プログラムを識別する識別子、当該プログラムの更新に要する時間（更新時間）及び更新を開始するスケジュールの候補が格納された表が用いられる。この表は、プログラムの属性や容量等に基づいて予め設定したものを用いればよい。

スケジュール候補決定部１３は、使用状況学習ＤＢ１０及びプログラム更新情報１１を参照可能に構成されており、車両３の使用状況及びプログラムの更新時間に基づいて、車両３のプログラムを更新するスケジュールの候補を決定する機能を有している。スケジュール候補決定部１３は、例えば、車両３の使用状況に基づいて、車両３がユーザ（利用者）に利用されていない空き時間を判定し、空き時間のうちプログラムの更新時間以上に時間を確保することができる空き時間を、プログラム更新が可能な空き時間であると予測する機能を有している。そして、スケジュール候補決定部１３は、予測した空き時間に基づいてリプログラムのスケジュールの候補を決定する機能を有している。スケジュール候補決定部１３は、条件を満たす空き時間が複数存在する場合には、リプログラムのスケジュールの候補を複数決定したり、所定の数に絞ったりする機能を有している。さらに、スケジュール候補決定部１３は、スケジュールの候補に関する情報を、スケジュール候補提示部１４及びリプログラム処理部１５へ出力する機能を有している。

スケジュール候補提示部１４は、スケジュール候補決定部１３により出力されたスケジュールの候補の時間帯における過去の車両状況を参照し、当該スケジュールの候補の時間帯における車両状況を予測する機能を有している。そして、スケジュール候補提示部１４は、スケジュール候補決定部１３により出力されたスケジュールの候補に関する情報、及び、当該スケジュールの候補の時間帯における予測した車両状況を車両３へ送信する機能を有している。

リプログラミングデータ１２は、車両３のプログラムを更新に用いられるデータである。リプログラム処理部１５は、スケジュール候補決定部１３が出力したスケジュールの候補のうちユーザにより選択されたスケジュールに基づいて、車両３のプログラムを更新する機能を有している。例えば、リプログラム処理部１５は、ユーザにより選択されたスケジュールにより指定された時刻に、リプログラミングデータ１２を参照して車両３のプログラムを更新する機能を有している。なお、ユーザによる選択操作は、図示しない通信装置が入力手段として機能することで車両３側から入力される。

サーバ２と通信可能に構成された車両３は、使用状況検出部３０、ディスプレイ３１、ユーザ選択操作部３２及びプログラム３３を備えている。

使用状況検出部３０は、車両３の使用状況を検出する機能を有している。使用状況検出部３０は、例えば、カレンダや時計を参照して年月日、曜日、時刻等の時間情報を取得するとともに、車両３に備わるＧＰＳ（Global Positioning System）受信機（不図示）等から位置情報を取得する機能を有している。また、使用状況検出部３０は、予め登録された停止場所の位置情報に基づいて、車両３が登録された位置情報に存在するか否か、存在する場合には登録された場所のうちどの場所に存在するのかを検出する機能を有している。登録された停止場所として、例えば、自宅車庫、勤務先駐車場、他駐車場等が用いられる。また、使用状況検出部３０は、例えばイグニッションＯＮの回数や位置情報等に基づいて、車両３の使用回数を取得する機能を有している。そして、使用状況検出部３０は、時間情報に対して使用回数及び停止場所を関連付けして、サーバ２へ送信する機能を有している。送信された情報は、サーバ２の使用状況学習ＤＢ１０に格納され蓄積される。

ディスプレイ３１は、サーバ２から送信されたリプログラミングのスケジュールの候補及び予測位置情報を表示する機能を有している。また、ユーザ選択操作部３２は、ディスプレイ３１に表示されたスケジュールの候補を選択決定するユーザ操作を入力可能に構成されている。ユーザ選択操作部３２として、例えばタッチパネルや操作ボタン等が用いられる。また、プログラム３３は、例えば車両３の車両制御、走行制御、その他制御に関するプログラムであり、サーバ２のリプログラム処理部１５により更新可能に構成されている。

上記構成のサーバ２及び車両３が互いに通信することにより車両３のプログラム３３が更新される。

次に、本実施形態に係るソフトウェア更新装置１の動作について説明する。図３は、本実施形態に係るソフトウェア更新装置１の動作を示すフローチャートである。図３に示す制御処理は、例えば車両３のプログラム更新の要求を得たタイミングから、所定のタイミングで繰り返し実行される。

図３に示すように、ソフトウェア更新装置１は、使用状況入力処理から開始する（Ｓ１０）。Ｓ１０の処理は、スケジュール候補決定部１３が実行し、使用状況学習ＤＢ１０を参照して車両３の使用状況を入力する処理である。例えば、使用状況学習ＤＢ１０には、図５（ａ）に示すように、月初めから数えた週番号を行、曜日を列としたカレンダ形式で使用回数を表現する表が格納されている。また、例えば、使用状況学習ＤＢ１０には、図５（ｂ）に示すように、時間帯を行、曜日を列とした時間割り形式で使用回数及び停止場所を表現する表が格納されている。停止場所は、自宅車庫、勤務先駐車場、他の駐車場に区分されている。スケジュール候補決定部１３は、使用状況学習ＤＢ１０を参照して、図５（ａ），（ｂ）に示す表を入力する。Ｓ１０の処理が終了すると、プログラム更新情報入力処理へ移行する（Ｓ１２）。

Ｓ１２の処理は、スケジュール候補決定部１３が実行し、プログラム更新情報１１を参照して更新するプログラムのリプログラミングに関する情報を入力する処理である。例えば、プログラム更新情報１１には、図４に示すように、プログラム識別子、リプログラミングに要する時間、参考開始スケジュールを示す表が格納されている。スケジュール候補決定部１３は、プログラム更新情報１１を参照して、図４に示す表を入力する。Ｓ１２の処理が終了すると、スケジュール候補決定処理へ移行する（Ｓ１４）。

Ｓ１４の処理は、スケジュール候補決定部１３が実行し、Ｓ１０及びＳ１２の処理で入力した情報に基づいて、車両３のプログラムを更新するスケジュールの候補を決定する処理である。最初に、スケジュール候補決定部１３は、図５（ａ）に示す表を参照し、表の中から所定の閾値以下の使用回数となった日を選択する。ここで閾値を例えば０とすると、太枠で示す日曜日（第２，４，５週）、金曜日（第１，３，５週）、土曜日（第４週）を候補の日として選択する。次に、スケジュール候補決定部１３は、図４に示す表を用いて、表の中から更新対象プログラムの更新に要する時間を参照する。ここでは更新対象のプログラムが識別子Ｃのプログラムであるとすると、図４に示す表に基づいて、更新に要する時間は６０分となる。そして、スケジュール候補決定部１３は、図５（ｂ）に示す表を参照し、図５（ａ）を用いて決定した日曜日、金曜日、土曜日のうち、車両３が使用されていない時間が連続して６０分以上確保できると予測される時間帯を選択する。例えば、日曜日、金曜日、土曜日の０時から１時の時間帯をスケジュールの候補として選択する。なお、スケジュールの候補が多数存在する場合には、近い将来の順に所定の数のスケジュール候補を選択する。Ｓ１４の処理が終了すると、スケジュール提示処理へ移行する（Ｓ１６）。

Ｓ１６の処理は、スケジュール候補提示部１４が実行し、Ｓ１４の処理で決定したスケジュールの候補と、当該スケジュールが示す時間帯における車両の予測停止場所とをあわせてユーザへ提示する処理である。スケジュール候補提示部１４は、図５（ｂ）に示す表を参照して、当該スケジュールが示す時間帯における車両の停止場所を予測する。そして、スケジュール候補提示部１４は、車両３のディスプレイ３１にスケジュール候補と予測停止場所とを表示させる。Ｓ１６の処理が終了すると、ユーザ選択受付処理へ移行する（Ｓ１８）。

Ｓ１８の処理は、リプログラム処理部１５が実行し、ユーザ操作を受付ける処理である。リプログラム処理部１５は、車両３のユーザ選択操作部３２により選択したユーザ操作を、車両３から通信を介して受付ける。Ｓ１８の処理が終了すると、リプログラム実行処理へ移行する（Ｓ２０）。

Ｓ２０の処理は、リプログラム処理部１５が実行し、車両３のプログラム３３を更新する処理である。リプログラム処理部１５は、Ｓ１８の処理でユーザにより選択されたスケジュールが示す時間帯に、リプログラミングデータ１２を用いてプログラム３３を更新する。Ｓ２０の処理が終了すると、図３に示す制御処理を終了する。

以上で図３に示す制御処理を終了する。図３に示す制御処理を実行することにより、ユーザにリプログラミングのスケジュールの候補を提示する際に、予測される車両の位置情報をあわせて提示することができるので、更新予定の時間帯が車両３の停止時間帯であるか否かを、ユーザに容易に判断させることが可能となる。

上述したように、本実施形態に係るソフトウェア更新装置１によれば、スケジュール候補提示部１４により、予測された空き時間帯と当該予測空き時間帯における予測された位置情報とがユーザに報知される。このため、ユーザに対して、報知された位置情報に基づいて、報知された空き時間帯の妥当性を検証させることができる。よって、ソフトウェア更新処理を行う時間帯の妥当性をユーザに判断させることが可能となる。また、予定したリプログラミングの時間帯における車両の使用状況をユーザに検証させることができるので、車両が使用されていない時間帯にリプログラミングを確実に実施することが可能となる。よって、効率的にリプログラミングを実施することができる。

また、本実施形態に係るソフトウェア更新装置１によれば、スケジュール候補決定部１３により、使用状況学習ＤＢ１０に格納された使用状況に基づいて、プログラム３３の更新可能な空き時間帯を予測することができる。よって、使用状況に基づいて車両３を使用しない可能性の高い空き時間帯を予測することができる。

また、スケジュール候補決定部１３は、プログラム３３の更新に要する時間に基づいてプログラム３３の更新可能な空き時間帯を予測することができる。よって、プログラム３３の更新に要する時間を考慮して、空き時間帯でプログラム３３の更新が可能であるか否かを判定することができるので、ソフトウェアの更新が可能な空き時間帯を予測することが可能となる。

なお、上述した実施形態は本発明に係るソフトウェア更新装置の一例を示すものである。本発明に係るソフトウェア更新装置は、実施形態に係るソフトウェア更新装置に限られるものではなく、各請求項に記載した要旨を変更しない範囲で、実施形態に係るソフトウェア更新装置を変形し、又は他のものに適用したものであってもよい。

例えば、上述した実施形態では、車両３がディスプレイ３１を備えることで、ユーザにスケジュールの候補を報知できる構成とした例を説明したが、スピーカ等を用いてユーザにスケジュールの候補を報知する場合であってもよい。

また、上述した実施形態では、図５（ｂ）に示す表を用いてプログラム３３の更新の時間帯を決定する例を説明したが、例えば、図４に示すプログラムごとに予め設定されている参考開始スケジュールを用いてプログラム３３の更新の時間帯を決定してもよい。

また、上述した実施形態では、図２に示すように、サーバ２側に、使用状況学習ＤＢ１０、スケジュール候補決定部１３及びスケジュール候補提示部１４を備えている例を説明したが、上記構成要素は、車両３側に備えてもよい。

また、上述した実施形態では、移動体として車両を用いて説明したが、車両に限られるものではなく、駐車する移動体であればよく、バイク、自転車、電車等であっても良い。

さらに、上述した実施形態では、図５に示す表を用いて使用状況学習ＤＢ１０の格納情報を説明したが、図５に示す表に限られるものではなく、例えば、時間帯を柔軟に定義したり、休日を任意に設定したり、祝日を考慮したり、駐車位置を柔軟に定義したものでもよい。

１…ソフトウェア更新装置、２…サーバ、３…車両、１０…使用状況学習ＤＢ、１１…プログラム更新情報、１２…リプログラミングデータ、１３…スケジュール候補決定部（予測手段）、１４…スケジュール候補提示部（報知手段）、１５…リプログラム処理部（更新手段）、３０…使用状況検出部、３１…ディスプレイ、３２…ユーザ選択操作部、３３…プログラム。

Claims

移動体と通信可能に構成され、利用者が前記移動体を使用しない空き時間帯に前記移動体のソフトウェアを更新するソフトウェア更新装置であって、
前記ソフトウェアの更新可能な前記空き時間帯を予測する予測手段と、
前記予測手段により予測された前記空き時間帯を前記利用者に報知する報知手段と、
前記報知手段により報知された前記空き時間帯の中から所定の空き時間帯を指定する前記利用者の操作を入力する入力手段と、
前記利用者により指定された前記空き時間帯で前記ソフトウェアの更新を行う更新手段と、
を備え、
前記報知手段は、前記空き時間帯を前記利用者に報知する際に、当該空き時間における前記移動体の予測される位置情報をあわせて報知すること、
を特徴とするソフトウェア更新装置。
前記予測手段は、前記移動体の稼動情報に基づいて前記ソフトウェアの更新可能な前記空き時間帯を予測する請求項１に記載のソフトウェア更新装置。
前記予測手段は、前記ソフトウェアの更新に要する時間に基づいて前記ソフトウェアの更新可能な前記空き時間帯を予測する請求項１又は２に記載のソフトウェア更新装置。