以下では、図1〜図13を参照しながら、本発明の実施形態を説明する。
(第1の実施形態)
図1は、本発明の第1の実施形態に係るソフトウェア更新システムの構成例を示す図である。
図1に示す通り、本発明の第1の実施形態に係るソフトウェア更新システムは、テレマティクスセンタ100と、車両200と、携帯端末300と、テレマティクスセンタ100と車両200の間で通信を可能とするネットワーク400と、テレマティクスセンタ100と携帯端末300の間で通信を可能とするネットワーク500とを有する。
テレマティクスセンタ100は、車両200の所有者であるユーザからソフトウェア適用の許諾を取得し、車両200に搭載されるECUの更新ソフトウェアを配信する。テレマティクスセンタ100は、ECUのソフトウェアの更新を管理するサーバである。車両200は、ソフトウェアの遠隔更新装置であるソフトウェア更新装置210を含んで構成される。携帯端末300は、ユーザの操作により、ソフトウェア更新の許諾結果をテレマティクスセンタ100に送信する。
ネットワーク400およびネットワーク500としては、例えば携帯電話網、インターネット網、無線LAN(Local Area Network)等の近距離無線通信網、あるいはそれら複数の通信網の組み合わせで構成されたものなどが挙げられる。なお、ネットワーク400およびネットワーク500は、共通のネットワークであってもよい。
図1では、テレマティクスセンタ100に接続される車両200および携帯端末300をそれぞれ1台ずつのみ示しているが、これらは1台に限定するものではない。以下の説明では、複数の車両200がテレマティクスセンタ100に接続されるものとする。
テレマティクスセンタ100は、中央演算処理装置110と、記憶装置120と、入出力装置130と、通信部140とから構成される。入出力装置130は、タッチパネルやキーボード、マウスなどの組み合わせから構成され、入力部および表示部として機能する。
中央演算処理装置110は、例えばCPU(Central Processing Unit)やFPGA(Field Programable Gate Array)などのプロセッサ、RAM(Random Access Memory)などから構成される。中央演算処理装置110は、これらを用いて所定の動作プログラムを実行することで、テレマティクスセンタ100の各種機能を実現するための処理を行う。中央演算処理装置110は、その機能として、更新案件管理部111、紐付情報管理部112、ユーザ許諾取得部113、更新データ配信部114、更新条件変更部115などを有する。
更新案件管理部111は、リコールなどのソフトウェア更新を要する事象を一意に管理する。紐付情報管理部112は、車両200の所有車であるユーザを一意に特定する。ユーザ許諾取得部113は、携帯端末300を介して、ユーザからソフトウェア更新の実行許諾を取得する。更新データ配信部114は、ソフトウェア更新のための新しいソフトウェアを車両200に配信する。更新条件変更部115は、新しいソフトウェアをECUに適用するための条件を変更する。
記憶装置120は、例えば、HDD(Hard Disk Drive)、SSD(Solid State Drive)、フラッシュメモリ、ROM(Read Only Memory)などから構成される。記憶装置120には、中央演算処理装置110が実行するプログラムや、プログラムの実行に必要なデータ群などが格納される。記憶装置120に格納されるデータ群には、更新案件DB121、車両構成DB122、ユーザ車両紐付DB123、ソフトウェア管理DB124などが含まれる。
更新案件DB121は、ソフトウェア更新案件の情報を蓄積する。車両構成DB122は、販売された車両200にどのようなECUが搭載されているか等、車両の構成情報を蓄積する。ユーザ車両紐付DB123は、ユーザと車両200の紐付情報を蓄積する。ユーザと車両200の紐付情報は、どのユーザがどの車両200を保有しているかの関係を示す情報である。ソフトウェア管理DB124は、車両200に配信するソフトウェアを蓄積する。なお、ソフトウェア管理DB124には、テレマティクスセンタ100が構築された環境のオペレーティングシステムに付属するファイルシステムなどを利用してもよい。
通信部140は、ネットワーク400およびネットワーク500で用いられる通信規格に準拠したネットワークカードなどから構成される。ネットワークカードは、例えば、有線LANなどの有線通信や無線LANなどの無線通信、あるいはその両方に必要な通信規格に準拠する。通信部140は、ネットワーク400、500をそれぞれ介して、車両200および携帯端末300と各種プロトコルに基づきデータを送受信する。
車両200は、ソフトウェア更新装置210と、エンジンECU220と、ECU230およびECU240と、電源管理ECU250と、蓄電池(バッテリー)260と、位置測位装置270と、通信部280とから構成される。
エンジンECU220は、車両200のエンジンの動作を管理する。ECU230およびECU240は、本実施形態において、ソフトウェアの更新対象となるECUである。電源管理ECU250は、車両200の電源を管理する。蓄電池260は、鉛蓄電池などから構成され、鉛蓄電池などの電力を蓄積する。位置測位装置270は、GPS(Grobal Positioning System)や無線LANなどを用いて測位を行い、車両200の位置情報を取得する。各機器は、CAN(Controller Area Network)などの車内ネットワークで接続される。
なお、各ECUには、自身を動作させるためのソフトウェアが内蔵されている。ECU自身を動作させるためのソフトウェアは、各ECUが持つ記憶装置に格納されている。
なお、車両200に搭載される、ソフトウェア遠隔更新が可能なECUは2つに限定するものでなく、1つであってもよく、任意の複数であってもよい。ソフトウェア更新装置210と位置測位装置270と通信部280とは、同一の機器であってもよいし、異なる機器であってもよい。また、ソフトウェア更新装置210は、車両200とは別の独立した電子機器であってもよい。具体的には、自動車に搭載されるPND(Portable Navigation Device)、スマートフォン、ドライブレコーダや、携帯端末を自動車に固定するためのクレードルなど、それらの組み合わせにて構成されることが考えられる。これらの端末は、例えばOBD(On Board Diagnostics)などのコネクタを用いることで、エンジンECU220、ソフトウェア更新対象のECU230およびECU240、電源管理ECU250などとデータを送受信することが考えられる。
ソフトウェア更新装置210は、中央演算処理装置211および記憶装置215から構成される。中央演算処理装置211は、例えばCPUやFPGAなどのプロセッサ、RAMなどから構成され、これらを用いて所定の動作プログラムを実行することで、車両200の各種機能を実現する処理を行う。中央演算処理装置211は、その機能として、更新案件確認部212、更新データ要求部213、ソフトウェア更新部214などを有する。
更新案件確認部212は、ソフトウェア更新が必要な案件があるか否かを、テレマティクスセンタ100に問い合わせる。更新データ要求部213は、ソフトウェア更新案件があった場合に、新しいソフトウェアやアップデート実行要件を更新データとして、テレマティクスセンタ100に要求する。ソフトウェア更新部214は、受信したソフトウェアおよびアップデート実行要件に基づいてECUのソフトウェアを更新し、その実行結果をテレマティクスセンタ100に送信する。
記憶装置215は、例えば、HDD、SSD、フラッシュメモリ、ROMなどから構成される。記憶装置215には、中央演算処理装置211が実行するプログラム、プログラムの実行に必要なデータ群などが格納される。記憶装置215には、ソフトウェア更新のための新しいソフトウェアが格納される。
通信部280は、ネットワーク400で用いられる通信規格に準拠したネットワークカードなどから構成される。ネットワークカードは、例えば、有線通信や無線通信、あるいはその両方に必要な通信規格に準拠する。通信部280は、ネットワーク400を介して、テレマティクスセンタ100と各種プロトコルに基づきデータを送受信する。
携帯端末300は、中央演算処理装置310と、記憶装置320と、入出力装置330と、通信部340とから構成される。入出力装置330は、タッチパネルやキーボード、マウスなどの組み合わせから構成され、入力部および表示部として機能する。
中央演算処理装置310は、例えばCPUやFPGAなどのプロセッサ、RAMなどから構成され、所定の動作プログラムを実行することで、携帯端末300の各種機能を実現する処理を行う。中央演算処理装置310は、その機能として、更新情報表示部311、許諾結果送信部312などを有する。
更新情報表示部311は、テレマティクスセンタ100から送信されるソフトウェア更新に関する情報を受信し、入出力装置330に表示させる。許諾結果送信部312は、入出力装置330を介して取得したユーザ許諾情報を、テレマティクスセンタ100に送信する。
記憶装置320は、例えば、HDD、SSD、フラッシュメモリ、ROMなどから構成され、中央演算処理装置310が実行するプログラム、およびプログラムの実行に必要なデータ群などが格納される。
通信部340は、ネットワーク500で用いられる通信規格に準拠したネットワークカードなどから構成される。ネットワークカードは、例えば、有線通信や無線通信、あるいはその両方に必要な通信規格に準拠する。通信部340は、ネットワーク500を介して、テレマティクスセンタ100と各種プロトコルに基づきデータを送受信する。
図2は、本発明の第1の実施形態において、テレマティクスセンタ100の車両構成DB122、ユーザ車両紐付DB123の各データベース(DB)に格納されるデータの構造を表すテーブルの一例を示す図である。図2(a)は車両構成DB122に格納されるテーブル例を示し、図2(b)はユーザ車両紐付DB123に格納されるテーブル例を示す。
図2(a)において、車両構成DB122には、VIN(Vehicle Identification Number)600、車種ID601、ECUID602、ソフトウェアバージョン603などの各データが格納される。VIN600は、車両200を一意に特定可能な識別子である。車種ID601は、そのVIN600を持つ車両200の車種を一意に特定可能な識別子である。ECUID602は、そのVIN600を持つ車両200に搭載されるECUを一意に特定可能な識別子である。ソフトウェアバージョン603は、ECUに搭載されているソフトウェアのバージョン情報を一意に特定可能な識別子である。
図2(b)において、ユーザ車両紐付DB123には、VIN610、ユーザID611、メールアドレス612などの各データが格納される。ユーザID611は、ユーザを一意に特定可能な識別子である。メールアドレス612は、ユーザID611に紐付くユーザの携帯端末300に、ソフトウェアの更新情報を配信するために用いられる。
図3は、本発明の第1の実施形態において、テレマティクスセンタ100の更新案件DB121に格納されるデータの構造を表すテーブルの一例を示す図である。図3(a)、図3(b)、図3(c)は、それぞれ更新案件DB121に格納される第1のテーブルの一例、第2のテーブルの一例、第3のテーブルの一例を示す図である。
図3(a)において、更新案件DB121の第1のテーブルは、更新案件ID700、ECUID701、ファイル名702、更新方式703、適用バージョン704、依存関係705などから構成される。更新案件ID700は、リコールなどの複数車両を対象としたソフトウェアアップデートを要する案件を一意に特定可能な識別子である。ECUID701は、その更新案件がアップデート対象とするECUの識別子を示す。ファイル名702は、アップデート対象のECUに適用する新しいソフトウェアの所在を示す。更新方式703は、新しいソフトウェアがどのような形態で作成されたかを示す。適用バージョン704は、新しいソフトウェアを適用してアップデートされた後のソフトウェアバージョンを示す。依存関係705は、複数のECUを同時に更新する案件の場合に、複数のECU間にソフトウェアの依存関係が存在するか否かを示す。
図3(b)において、更新案件DB121の第2のテーブルは、更新案件ID710、車種ID711、更新時間712、予想消費電力713、実行判断閾値714、対象台数715、完了台数716などから構成される。車種ID711は、その更新案件が対象とするECUを搭載する車種の識別子を示す。更新時間712および予想消費電力713は、更新案件によるアップデートに要する予想更新時間および予想消費電力を示す。実行判断閾値714は、更新案件に基づくアップデートの実行可否を判断する基準である、蓄電池260の残電力量の閾値を示す。対象台数715は、この更新案件が対象とする車両200の全台数を示す。完了台数716は、既にアップデートが完了した車両200の台数を示す。
図3(c)において、更新案件DB121の第3のテーブルは、更新案件ID720、VIN721、ユーザ許諾722、更新日時723、実績消費電力724、ファイル伝送速度(ソフトウェア伝送速度)725、ロールバック実行回数726、消費電力ログ情報727、更新実行位置728などから構成される。
図3(c)において、VIN721は、その案件が対象とする車両200の識別子を示す。ユーザ許諾722は、対象の車両200の所有車であるユーザからアップデート実行の許諾を取得済みであるかを示す。更新日時723は、アップデートが完了した場合に、アップデート実行日時を格納する。実績消費電力724は、アップデートに要した消費電力の実績値を示す。ファイル伝送速度725は、新しいソフトウェアのダウンロードに成功した場合のファイル伝送速度を示す。ロールバック実行回数726は、アップデート時にロールバック処理を実行したか否か、ロールバック処理を実行した場合は何回ロールバックを実行したかを示す。消費電力ログ情報727は、アップデート実行時にECU毎やステップ毎などで消費した電力量を示す。更新実行位置728は、アップデートを実行した時の車両200の位置情報を示す。
図4は、本実施形態のソフトウェア更新システムにおけるソフトウェア更新案件の登録からユーザ許諾までの処理の一例を示す図である。図4に示す処理は、テレマティクスセンタ100の更新案件管理部111、紐付情報管理部112およびユーザ許諾取得部113と、携帯端末300の更新情報表示部311および許諾結果送信部312とでそれぞれ行われる。
図4において、テレマティクスセンタ100の更新案件管理部111は、入出力装置130を介して、システム管理者からECUの更新案件の登録を受け付ける(S800)。システム管理者とは、テレマティクスセンタ100の運用者や、ECUの製造管理者などが考えられる。更新案件管理部111は、対象ECUID、アップデートファイル、更新方式、新しいバージョン、および複数ECUを更新する場合はその依存関係に関する情報をそれぞれ受け付ける。更新案件管理部111は、新しく更新案件ID700を生成した後に、更新案件DB121のECUID701〜依存関係705に、受け付けた情報をそれぞれ蓄積する。このとき、更新案件管理部111は、対象となる車種、システム管理者等が予想する更新時間および消費電力と、更新実行の判断となる蓄電池260の残電力量の閾値に関する情報とを受け付ける。更新案件管理部111は、生成した更新案件IDと共に、更新案件DB121の更新案件ID710〜実行判断閾値714に、それぞれの情報を蓄積する。
更新案件管理部111は、新しい更新案件を受け付けると、更新対象であるECUID701を持つ車両200を車両構成DB122から検索する(S801)。更新案件管理部111は、該当する車両200の台数を、更新案件DB121の対象台数715に蓄積する。また、更新案件管理部111は、該当する車両200の全てのVIN600を、生成した更新案件IDと共に、更新案件DB121の更新案件ID720、VIN721に蓄積する。
紐付情報管理部112は、更新案件として登録されたVIN721を持つ車両200のユーザにソフトウェアの更新情報を送信するべく、ユーザ車両紐付DB123からユーザID611およびメールアドレス612を検索する(S802)。ユーザ許諾取得部113は、メールアドレス612のリストに対して、更新情報としてメールを送信する(S803)。
携帯端末300の更新情報表示部311は、テレマティクスセンタ100から更新情報を受信する(S810)。更新情報表示部311は、更新情報の内容とアップデート実行の許諾取得に関する情報を、入出力装置330に表示させる(S811)。携帯端末300の許諾結果送信部312は、入出力装置330を介して得られたユーザの許諾選択結果を、テレマティクスセンタ100に送信する(S812)。なお、例えばメールなどの通知方法では、ステップS810、ステップS811、ステップS812に時間を要することが考えられる。
テレマティクスセンタ100のユーザ許諾取得部113は、携帯端末300から許諾選択結果を受信する(S804)。ユーザ許諾取得部113は、送付元のメールアドレスを用いてユーザ車両紐付DB123を検索し、送付したユーザが所有するVIN610を特定する。ユーザ許諾取得部113は、さらに、VIN610と同一のVINを示すVIN721を持つ更新案件DB121のレコードについて、ユーザ許諾722を更新する。
図5は、本実施形態のソフトウェア更新システムにおけるソフトウェアのダウンロードに関する処理の一例を示す図である。図5に示す処理は、車両200の更新案件確認部212および更新データ要求部213と、テレマティクスセンタ100の更新案件管理部111とでそれぞれ行われる。
図5において、車両200の更新案件確認部212は、エンジンECU220からの情報を用いてエンジン始動を検知する(S900)。更新案件確認部212は、エンジン始動を検知すると、まだ完了していない更新案件が存在するか否かを確認するため、テレマティクスセンタ100に対して問い合わせを実行する(S901)。
テレマティクスセンタ100の更新案件管理部111は、車両200から更新案件の問い合わせを受信する(S910)。更新案件管理部111は、問い合わせ元の車両200のVINが、更新案件DB121のVIN721に登録されているか否かを確認する(S911)。VINが登録されていた場合には、更新案件管理部111は、該当するレコードのユーザ許諾722を確認し、既にユーザ許諾を取得済みであるか否かを確認する(S913)。そして、更新案件管理部111は、VINが登録されているか否か及びユーザ許諾を取得済みであるか否かの、2つの確認結果を車両200に送信する(S914)。
車両200の更新案件確認部212は、テレマティクスセンタ100から更新案件の確認結果を受信する(S902)。更新案件確認部212は、更新案件がありかつユーザ許諾が得られている場合には、更新データ要求部213を用いて、更新対象ECUの新しいソフトウェアと更新実行要件をテレマティクスセンタ100に要求する(S903)。更新実行要件は、更新実行の判断基準となる残電力量の閾値に関する情報などである。
テレマティクスセンタ100の更新案件管理部111は、車両200からソフトウェアダウンロードの要求を受信する(S915)。更新案件管理部111は、問い合わせ元の車両200のVINが、更新案件DB121のVIN721に登録されているか否かを確認する。VINが登録されていた場合には、更新案件管理部111は、該当レコードの更新案件ID720を用いて更新案件DB121の更新案件ID700を含むテーブルを検索することで、ソフトウェアアップデートに必要なファイル名702を抽出する。更新案件管理部111は、さらに、更新案件ID720を用いて更新案件DB121の更新案件ID710を検索して、更新時間712〜実行判断閾値714を抽出する。そして、更新案件管理部111は、対象のファイル名702を用いて更新用ソフトウェアを抽出する。更新案件管理部111は、更新用ソフトウェアおよび更新実行要件としての更新時間712〜実行判断閾値714に関する情報を、車両200に送信する(S916)。
車両200の更新データ要求部213は、テレマティクスセンタ100から新しいソフトウェアと更新実行要件を受信する(S904)。更新データ要求部213は、それらのデータを記憶装置215に蓄積する(S905)。なお、更新案件がない、あるいはユーザ許諾がまだ得られていない場合には、ステップS903からステップS905は実行されない。
図6は、本実施形態のソフトウェア更新システムにおけるソフトウェアのインストールに関する処理の一例を示す図である。図6に示す処理は、車両200のソフトウェア更新部214と、テレマティクスセンタ100の更新案件管理部111、紐付情報管理部112およびユーザ許諾取得部113と、携帯端末300の更新情報表示部311とでそれぞれ行われる。
車両200のソフトウェア更新部214は、エンジンECU220からの情報を用いて、エンジン停止を検知する(S1000)。ソフトウェア更新部214は、エンジン停止を検知すると、電源管理ECU250を介して蓄電池260の残電力量を確認する(S1001)。ソフトウェア更新部214は、記憶装置215に新しいソフトウェアが蓄積されているか否か、および、蓄電池260の残電力量がソフトウェアの更新実行要件である残電力量の閾値を上回っているか否かを確認する(S1002)。ソフトウェア更新部214は、新しいソフトウェアが格納されており、かつ残電力量が閾値を上回っている場合(S1002:Yes)には、テレマティクスセンタ100にアップデートを開始できることを示す情報を送信する(S1003)。
テレマティクスセンタ100の更新案件管理部111は、車両200からアップデートの実行可能を示す情報を受信すると、車両200の更新案件に対応する更新案件ID710のレコードから、更新時間712〜実行判断閾値714の情報を検索する。更新案件管理部111は、図4に示すステップS802〜ステップS803と同様の方法で、ユーザが所有する携帯端末300に対して、更新情報と共にアップデート開始に関する情報を通知する(S1010)。アップデート開始に関する情報には、例えば、更新時間712〜実行判断閾値714の情報が含まれる。
携帯端末300の更新情報表示部311は、テレマティクスセンタ100からアップデートの開始情報を受信すると、アップデートに要する時間や消費電力などの情報を、入出力装置330に表示させる(S1020)。そして、許諾結果送信部312は、入出力装置330を介してユーザからのアップデート実行に対する許諾を取得し、テレマティクスセンタ100に送信する(S1021)。
テレマティクスセンタ100は、携帯端末300からのアップデート実行許諾を取得すると、ステップS804と同様の手順で、発信元メールアドレスからユーザが所有する車両200のVINを特定する。テレマティクスセンタ100は、さらに、該当する車両200に対して、許諾情報を転送する(S1011)。
車両200のソフトウェア更新部214は、テレマティクスセンタ100から許諾情報を受信する(S1004)。ソフトウェア更新部214は、記憶装置215に蓄積された新しいソフトウェアを用いて、対象ECUのソフトウェア更新処理を実行する(S1005)。なお、このステップS1005で行われる処理の詳細については、図7を用いて後述する。そして、ソフトウェア更新部214は、アップデートが完了した後、その実行結果として、更新日時、実消費電力、ロールバック実行回数、車両200の位置情報などを、テレマティクスセンタ100に送信する(S1006)。
テレマティクスセンタ100の更新案件管理部111は、車両200からアップデートの実行結果を受信すると、車両200のVINから更新案件DB121のVIN721を検索する。更新案件管理部111は、検索されたVIN721のレコードの更新日時723〜更新実行位置728を更新する。また、更新案件管理部111は、該当レコードの更新案件ID720と同一のIDを持つ更新案件ID710について、完了台数716に1を加えて更新する。更新案件管理部111は、さらに、図4に示すステップS802〜ステップS803と同様の方法で、ユーザが所有する携帯端末300に対して、実行結果情報と共にアップデート完了を通知する(S1012)。
携帯端末300の更新情報表示部311は、テレマティクスセンタ100から実行結果情報を受信すると、アップデートの実行結果を入出力装置330に表示させる(S1022)。
新しいソフトウェアが格納されていない、あるいは残電力量が閾値を上回っていない場合(S1002:No)、更新を実行しなかったという結果を携帯端末300に送信するため、ステップS1006、ステップS1012、ステップS1022の処理を行う。なお、ECUのソフトウェアの更新を実行しなかった場合には、ステップS1022の処理は実行しなくともよい。
図7は、本実施形態のソフトウェア更新システムにおいて、図6のステップS1005で実行される処理の一例を示す図である。図7に示す処理は、ソフトウェア更新装置210と更新対象のECUとでそれぞれ行われる。ここでは、代表的にECU230をソフトウェアの更新対象としたシーケンスを示す。
図7において、ソフトウェア更新装置210のソフトウェア更新部214は、車内ネットワークを介して、ECU230にバージョン情報の取得要求を送信する(S1100)。ECU230は、ソフトウェア更新装置210からバージョン取得要求を受信する(S1110)。ECU230は、自身のソフトウェアバージョンを示す情報を、ソフトウェア更新装置210に送信する(S1111)。ソフトウェア更新部214は、ECU230からバージョン情報を受信する(S1101)。ソフトウェア更新部214は、受信したバージョン情報が示すソフトウェアバージョンが、更新用のソフトウェアのバージョンよりも古いことを確認し、更新対象のソフトウェアであることを特定する。
次に、ソフトウェア更新部214は、記憶装置215に蓄積したECU230用の更新ソフトウェアが差分ファイル・圧縮ファイルであった場合には、ECU230にそのデータを転送し、データを復元・解凍するよう要求を送信する(S1102)。ECU230は、ソフトウェア更新装置210からデータ復元・解凍要求を受信する(S1112)。ECU230は、受信したデータと自身の現在のソフトウェアを用いて更新後のデータを復元・解凍して、ECU230の内部(ECU230が有する記憶装置)に記憶する。ECU230は、復元・解凍した結果を、ソフトウェア更新装置210に送信する(S1113)。
ソフトウェア更新装置210は、ECU230から復元・解凍結果を受信する(S1103)。ソフトウェア更新装置210は、ECU230に対して、ソフトウェアが格納されている記憶領域の一部分(Block)を消去するよう指示する(S1104)。ECU230は、ソフトウェア更新装置210から消去要求を受信する(S1114)。ECU230は、記憶装置から該当領域のデータを消去し、その結果をソフトウェア更新装置210に送信する(S1115)。ソフトウェア更新装置210は、ECU230から消去結果を受信する(S1105)。
ソフトウェア更新装置210は、ECU230に対して、復元・解凍された新しいソフトウェアを利用して、S1104で消去を指示した記憶装置のBlockに対して、新しいソフトウェアでの書き込みを命令する(S1106)。ECU230は、ソフトウェア更新装置210から書き込み要求を受信する(S1116)。ECU230は、記憶装置の該当ブロックを新しいソフトウェアの一部で書き込む。ECU230は、さらに、書き込みが成功したかあるいは失敗したかの情報を、ソフトウェア更新装置210に送信する(S1117)。
ソフトウェア更新装置210は、ECU230から書き込み結果を受信する(S1107)。ソフトウェア更新装置210は、書き込み結果が成功であるか否かを確認する(S1108)。ソフトウェア更新装置210は、書き込みに失敗したと判断した場合(S1108:No)には、再度書き込み処理を実行するべく、同一Blockに対して再度ステップS1104〜ステップS1107を実行する。
ソフトウェア更新装置210は、書き込みに成功したと判断した場合(S1108:Yes)には、ECU230の記憶装置の全てのBlockの書き込みが終了したか否かを判断する(S1109)。全てのBlockの書き込みが完了していない場合(S1109:No)には、ソフトウェア更新装置210は、前述とは異なるBlockに対してステップS1104〜ステップS1107を行う。ソフトウェア更新装置210は、全てのBlockの書き込みが完了するまで、ステップS1104〜ステップS1107の処理を繰り返す。
以上は、差分ファイルを圧縮したファイルを用いて、ソフトウェアを更新するシーケンス例を示しているが、更新案件DB121の更新方式703に格納される、ソフトウェアの更新方法に応じてその処理の取捨選択をしてもよい。例えば、差分も圧縮もしない完全なファイルを用いてソフトウェアを更新する場合には、ステップS1102〜ステップS1103は実行しなくともよい。
図8は、本実施形態のソフトウェア更新システムにおいて、テレマティクスセンタ100の更新条件変更部115による処理の一例を示す図である。更新条件変更部115は、更新案件DB121の実行判断閾値714を変更する処理を実行する。この処理の実行タイミングは、1時間周期などの定期的なものであっても、該当する更新案件のレコードの対象台数715が一定台数増加する度であっても、テレマティクスセンタ100の管理者が手動で実行するものであってもよい。また、図5のステップS901のアップデート情報の問い合わせ時に実行判断閾値714の変更処理を実行し、ステップS914の結果送信時に算出結果を送信するようにしてもよい。
図8において、テレマティクスセンタ100の更新条件変更部115は、更新案件DB121から、対象台数715が完了台数716と一致しない、すなわち全車両の更新が完了していない案件の更新案件ID710を1件抽出する(S1200)。
更新条件変更部115は、抽出した更新案件ID710を用いて、同一のIDを持つ更新案件ID720のレコードを全て検索し、その実績消費電力724およびロールバック実行回数726を収集する(S1201)。更新条件変更部115は、ロールバック実行回数726が0回であるレコードと、ロールバック実行回数726が1回以上であるレコードの2つにグループを分割する。更新条件変更部115は、さらに、2つのグループのレコード数を比較して、更新処理のロールバック発生確率PRを算出する(S1202)。更新条件変更部115は、各グループのレコードに含まれる実績消費電力724の情報から、更新処理に必要な電力量の分布を作成する(S1203)。
次に、更新条件変更部115は、作成した2つのグループの分布から、電力量の値Tをそれぞれ算出する(S1204)。電力量の値Tは、例えば、ソフトウェア更新に必要であった電力量(消費電力量)がT以下である車両の割合が、各グループのソフトウェア更新済みの車両に対してA%以上となるような値である。ロールバックせずアップデート完了したグループの分布から算出した電力量の値をT1、アップデート時にロールバックが発生したグループの分布から算出した電力量の値をT2とする。更新条件変更部115は、ロールバック発生確率PRと、算出したT1およびT2から、ソフトウェア更新時に必要となる可能性の高い電力量の期待値E、すなわち実行判断の閾値を算出する。そして、更新条件変更部115は、抽出した更新案件ID710のレコードの実行判断閾値714を変更する(S1205)。電力量の期待値Eは、例えば、次式にて算出される。
E=T1×(1−PR)+T2×PR
更新条件変更部115は、対象台数715が完了台数716と一致しない、すなわち全車両の更新が完了していない案件の更新案件ID710全てについて、実行判断閾値714の変更が完了したか否かを確認する(S1206)。
更新条件変更部115は、全ての更新案件に対して実行判断閾値714の変更が完了した場合(S1206:Yes)は、図8に示す処理を終了する。更新条件変更部115は、実行判断閾値714の変更が完了していない更新案件が存在する場合(S1206:No)は、ステップS1200〜ステップS1205の処理を繰り返す。
なお、ステップS1205で変更する実行判断閾値714の値は、必ずしもステップS1204で算出する期待値Eでなくてもよい。実行判断閾値714の値は、例えば、電力量の値T1あるいはT2をそのまま利用することや、該当する更新案件の全車両のアップデート実績の中で最も値の大きい実績消費電力724を利用してもよい。また、該当する更新案件のアップデートが完了した他の車両200の実績消費電力724を利用するのではなく、これからアップデートを実行する車両200が過去に別の更新案件でアップデートした時の実績消費電力724を利用して、実行判断閾値714を算出してもよい。
図9に、本実施形態のソフトウェア更新システムにおいて、テレマティクスセンタ100の入出力装置130に表示される画面の一例を示す。
図9において、テレマティクスセンタ100の入出力装置130には、更新案件に関する情報を示す領域1300、領域1301および領域1302が表示される。領域1301は、更新案件について、アップデート時にロールバックを実行しなかった車両200の消費電力量の分布を表示するための画面領域である。領域1302は、アップデート時にロールバックを実行した車両200の消費電力量の分布を表示するための画面領域である。
領域1300では、更新案件DB121の更新案件ID710に紐付くレコードの車種ID711、更新時間712、対象台数715、完了台数716などの更新案件の詳細な情報が表示される。また、領域1300には、更新案件についての実行判断閾値714の算出式と算出結果が表示される。さらに、領域1300には、テレマティクスセンタ100の管理者などにより、テレマティクスセンタ100に対して実行判断閾値714の更新要求を行うための操作領域が表示される。テレマティクスセンタ100の更新条件変更部115は、入出力装置130からの新しい閾値の入力に応じて、該当する更新案件の更新案件ID710のレコードの実行判断閾値714を更新する機能を有する。
領域1301は、ある更新案件の更新案件ID720を持つ全てのレコードの内、ロールバック実行回数726が0回であるレコードを対象に、横軸にアップデートに要した実際の消費電力である実績消費電力724を、縦軸にその車両200の割合を示している。 図9に示す例では、図8のステップS1204におけるA%の値を、90%と設定している。図9に示すように、ロールバックを実行せずアップデートが完了した車両の内、90%の車両が40Wh(ワットアワー)以下の消費電力、全ての車両が61Wh以下の消費電力で更新処理を完了したことを示している。
領域1302は、ある更新案件の更新案件ID720を持つ全てのレコードの内、ロールバック実行回数726が1回以上であるレコードを対象に、横軸に実績消費電力724を、縦軸にその車両200の割合を示している。図9に示すように、ロールバックを1回以上実行してアップデートを完了した車両の内、90%の車両が87Wh以下の消費電力、全ての車両が103Wh以下の消費電力で更新処理を実行できたことを示している。
図10に、本実施形態のソフトウェア更新システムにおいて、携帯端末300の入出力装置330に表示される画面の一例を示す。
図10において、携帯端末300の入出力装置330には、アップデート対象のECUがどのパーツに関するものかを可視化する領域1400と、更新内容の詳細情報を示す領域1401と、ユーザから許諾を取得するための領域1402とが表示される。
図10における画面は、ステップS811やステップS1020におけるユーザへの許諾取得に利用されるものであり、テレマティクスセンタ100から送信されたメールを表示した画面を想定している。領域1401では、携帯端末300のユーザが所有する車両200のソフトウェア更新に関する情報として、更新案件DB121の車種ID711やECUID701、更新時間712などの情報が表示される。領域1402では、実行判断閾値714に関する情報、ユーザがアップデート実行の可否を選択する領域などが表示される。ユーザによる選択結果は、ステップS812およびステップS1021において、許諾結果送信部312からテレマティクスセンタ100に送信される。
なお、本実施形態ではメールによるユーザへの通知方法を記載しているが、本発明はそれに限定するものではない。前述の通り、例えばソフトウェア更新装置210がPNDなどの端末であり、入出力装置を持つ電子機器である場合には、携帯端末300の入出力装置330の代わりにソフトウェア更新装置210の入出力装置にユーザ許諾などの画面を表示してもよい。
図10の表示画面は一例であり、少なくとも、アップデート対象の電子機器とソフトウェアが特定できる表示と、アップデート実行要否の表示を有する画面であれば、その表示内容、表示項目、デザインなどは問わない。
また、ソフトウェア更新装置210と携帯端末300は同一の機器であってもよい。この場合、ソフトウェア更新装置210がPNDなどの端末であり、入出力装置を持つ電子機器である場合には、携帯端末300の入出力装置330の代わりにソフトウェア更新装置210の入出力装置にユーザ許諾などの画面を表示してもよい。また、車両200と携帯端末300はテレマティクスセンタ100を介さずに直接通信しても良く、さらにテレマティクスセンタ100と携帯端末300は同一の機器であってもよい。
上述した実施形態によれば、次の作用効果が得られる。
(1)実施形態のソフトウェア更新システムは、車両200に搭載されるソフトウェア更新装置210とネットワーク400を介して通信を行うテレマティクスセンタ100とを備え、車両200のECU220〜250のソフトウェアの更新を管理する。テレマティクスセンタ100は、少なくとも、ECU220〜250がソフトウェアを更新する際に要した電力量に関する情報、すなわち実績消費電力に基づいて、ソフトウェアの更新の実行可否を判断する残電力量の閾値(電力量閾値)を演算して出力する中央演算処理装置(閾値演算制御部)110を備える。車両200の中央演算処理装置211は、テレマティクスセンタ100が残電力量の閾値を出力した後に受信したソフトウェア更新指令にしたがってソフトウェア更新処理を実行する。
実施形態では、テレマティクスセンタ100の中央演算処理装置110から携帯端末300に電力量閾値、残電力量などが表示され、ユーザはこの表示に基づいて更新実行の可否を決定する。ユーザが更新実行を指令すると、車両200の中央演算処理装置211は、該当するECUのソフトウェアを更新する。
本実施形態では、ソフトウェア更新の際の実績消費電力を収集し、ソフトウェア更新の実行判断の基準となる残電力量の閾値を決定する。このようにしたので、最適な残電力量の閾値を決定することができる。この結果、不意な消費電力量の増加による更新失敗に備えつつ、不用意に閾値を厳しく設定することで、ソフトウェア更新の適用が進まないという状況を回避することができる。
(2)テレマティクスセンタ100の中央演算処理装置110は、ソフトウェアの更新の際に実行したロールバック回数に関する情報と上記電力量に関する情報とに基づいて、電力量閾値を演算する。このようにしたので、ソフトウェアの更新の際に発生するロールバックを考慮して、更新に要する電力量の閾値を算出することができる。
(3)実施形態のソフトウェア更新システムは、テレマティクスセンタ100の中央演算処理装置110から出力された電力量閾値を受信して表示部に表示する携帯端末300をさらに含む。携帯端末300には車両200の残電力量も表示される。ユーザは、電力量閾値と残電力量とを比較してソフトウェアの更新の実行を判断することができ、ソフトウェア更新中に電力量が不足して更新が中断する不具合を防止することができる。
なお、特許文献1に記載の従来技術では、ソフトウェア更新時の車外環境(車内ネットワーク構成や通信速度など)を考慮しておらず、ハードウェア起因ではない原因で実行時間および消費電力量が増大する恐れがある。このようなケースで消費電力量が増加してしまった場合、アップデート中あるいはロールバック中にソフトウェア更新が中断されることになる。ソフトウェア更新が中断されて運転制御に関するECUのソフトウェア更新に失敗した場合には、次回運転時に自動車が操作できない可能性があり、容易にECUのソフトウェアを更新することができない。
一方で、ソフトウェア更新の実行判断の基準となる残電力量の閾値を厳しく設定(残電力量が90%以上など)してしまうと、自動車の安全性に関わるソフトウェアアップデートの適用に時間が掛かってしまうという問題もある。
上記第1の実施形態のソフトウェア更新システムでは、このような問題が解決される。
(第2の実施形態)
図11および図12に、本発明の第2の実施形態に係るソフトウェア更新システムによる処理の一例を示す。第2の実施形態に係るソフトウェア更新システムは、図1に示す第1の実施形態に係るソフトウェア更新システムと同様の構成を有している。また、テレマティクスセンタ100と携帯端末300との間のユーザ許諾取得に関する処理は、図4に示す第1の実施形態の処理と同様である。
図11は、第2の実施形態のソフトウェア更新システムにおけるソフトウェアのダウンロードおよびインストールに関する処理の一例を示す図である。図11に示す処理は、車両200の更新案件確認部212、更新データ要求部213およびソフトウェア更新部214と、テレマティクスセンタ100の更新案件管理部111および更新条件変更部115と、携帯端末300の更新情報表示部311および許諾結果送信部312とでそれぞれ行われる。図11に示す例では、第1の実施形態の図5および図6に示す、更新ソフトウェアのダウンロードおよびインストール処理を一体化した処理を実現している。
車両200の更新案件確認部212は、エンジンECU220からの情報を用いて、エンジン停止を検知する(S1500)。更新案件確認部212は、エンジン停止を検知すると、位置測位装置270から車両200の現在位置を取得する。また、更新案件確認部212は、通信部280を用いて、テレマティクスセンタ100との通信速度を測定する。更新案件確認部212は、現在位置および通信速度に関する情報と、まだ完了していない更新案件が存在するか否かを確認する問い合わせを、テレマティクスセンタ100に送信する(S1501)。
テレマティクスセンタ100の更新案件管理部111は、車両200から更新案件の問い合わせを受信する(S1510)。更新案件管理部111は、問い合わせ元の車両200のVINが、更新案件DB121のVIN721に登録されているか否かを確認する(S1511)。VINが登録されていた場合には、更新案件管理部111は、該当するレコードのユーザ許諾722を確認し、既にユーザ許諾を取得済みであるか否かを確認する(S1512)。ユーザ許諾が取得済みであった場合には、更新案件管理部111は、該当レコードの更新案件ID720を用いて更新案件DB121の更新案件ID710を検索して、更新時間712および予想消費電力713に関する情報を抽出する。
更新条件変更部115は、アップデート実行の判断基準となる、残電力量の閾値を計算する(S1513)。ステップS1513で行われる処理の詳細については、図12を用いて後述する。そして、更新案件管理部111は、ユーザ許諾の確認結果、更新時間712、予想消費電力713、およびステップS1513で算出した実行判断閾値714を、車両200に送信する(S1514)。
車両200の更新案件確認部212は、テレマティクスセンタ100から更新案件の確認結果を受信する(S1502)。更新案件確認部212は、更新案件がありかつユーザから許諾が得られている場合には、蓄電池260の残電力量がソフトウェアの更新実行要件である残電力量の閾値を上回っているか否かを確認する(S1503)。
更新案件確認部212は、更新案件がありかつ残電力量が閾値を上回っている場合(S1504:Yes)には、更新データ要求部213を利用して、更新対象ECUの新しいソフトウェアのダウンロードを、テレマティクスセンタ100に要求する(S1505)。
テレマティクスセンタ100の更新案件管理部111は、車両200からソフトウェアダウンロードの要求を受信する(S1515)。更新案件管理部111は、問い合わせ元の車両200のVINが、更新案件DB121のVIN721に登録されているか否かを確認する。VINが登録されていた場合には、更新案件管理部111は、該当レコードの更新案件ID720を用いて更新案件DB121の更新案件ID700を含むテーブルを検索して、ソフトウェアアップデートの必要なファイル名702を抽出する。そして、更新案件管理部111は、対象のファイル名702から更新用ソフトウェアを抽出し、更新用ソフトウェアを車両200に送信する(S1516)。
車両200の更新データ要求部213は、テレマティクスセンタ100から新しいソフトウェアを受信する(S1506)。更新データ要求部213は、受信したデータを記憶装置215に蓄積した上で、新しいソフトウェアを用いて対象ECUのソフトウェア更新処理を実行するする(S1507)。なお、ステップS1507で行われる処理は、図7に示す第1の実施形態の処理と同様である。そして、更新データ要求部213は、アップデートが完了した後、その実行結果をテレマティクスセンタ100に送信する(S1508)。ここで、実行結果は、更新日時、実消費電力、ロールバック実行回数、アップデートを実行した際の車両200の位置情報、ソフトウェアダウンロード時の伝送速度などを示す情報である。
テレマティクスセンタ100の更新案件管理部111は、車両200からアップデートの実行結果を受信すると、発信元の車両200のVINから更新案件DB121のVIN721を検索する。更新案件管理部111は、該当レコードの更新日時723〜更新実行位置728の情報を更新する。また、更新案件管理部111は、該当レコードの更新案件ID720と同一のIDを持つ更新案件ID710に対して、完了台数716に1を加えて更新する。さらに、更新案件管理部111は、図4に示す第1の実施形態のステップS802〜ステップS803と同様の方法で、ユーザが所有する携帯端末300に対して、実行結果情報と共にアップデート完了を通知する(S1517)。
携帯端末300の更新情報表示部311は、テレマティクスセンタ100から実行結果情報を受信すると、実行結果情報を入出力装置330に表示させる(S1520)。なお、更新案件がない、あるいは残電力量が閾値を上回っていない場合(S1504:No)には、更新を実行しなかったという結果を携帯端末300に送信するため、ステップS1508、ステップS1517、ステップS1520の処理を実行する。ECUのソフトウェア更新を実行しなかった場合には、ステップS1520の処理は実行しなくともよい。 また、図6に示す第1の実施形態のステップS1003〜ステップS1004の処理と同様に、ソフトウェアのダウンロードおよびインストールを実行する前に、ユーザから実行許諾を取得するようにしてもよい。
図12は、第2の実施形態のソフトウェア更新システムにおいて、テレマティクスセンタ100の更新条件変更部115により、図11のステップS1513で実行される処理の一例を示す図である。
図12において、テレマティクスセンタ100の更新条件変更部115は、図11のステップS1501でアップデート有無を問い合わせた車両200のVINを用いて、更新案件ID720を1件抽出する(S1600)。更新条件変更部115は、抽出した更新案件ID720を用いて、同一のIDを持つ更新案件ID720のレコードを全て検索し、既に更新が完了した車両についての実績消費電力724、ファイル伝送速度725、更新実行位置728を収集する(S1601)。更新条件変更部115は、図11のステップS1501で送信された車両200の現在位置を用いて、現在位置から距離Dkm以内となる更新実行位置728が存在するレコードを抽出する(S1602)。
更新条件変更部115は、さらに、図11のステップS1501で送信された通信速度Cbps(bit per second)を用いて、ファイル伝送速度725がCのTU%以下、かつCのTD%以上であるレコードを抽出する(S1603)。例えば、TUが105、TDが95であった場合、対象となるレコードは、通信速度がCの95%〜105%の範囲内に収まる環境下でソフトウェア更新が実行されたものとなる。なお、伝送速度を用いた閾値の決定方法はこれに限られるものではなく、例えば「CのTU%以下」や「CのTD%以上」という条件のどちらか一方のみを用いてもよい。
更新条件変更部115は、ステップS1603で抽出したレコードに含まれる実績消費電力724の情報から、更新処理に必要な電力量の分布を作成する(S1604)。次に、更新条件変更部115は、作成した電力量の分布から、「ソフトウェア更新に必要であった電力量(消費電力量)がその値以下である」車両の割合が、各グループの更新済みの車両に対してA%以上となるような電力量の値T3を算出する(S1605)。そして、更新条件変更部115は、算出したT3を、ソフトウェア更新時に必要となる可能性の高い電力量の期待値、すなわち実行判断の閾値として決定する(S1606)。決定された閾値は、図11に示すステップS1514にて、テレマティクスセンタ100から車両200に送信されることになる。
ステップS1606で決定する実行判断閾値の値は、必ずしもステップS1605で算出した値でなくてもよく、該当する更新案件の全車両のアップデート実績の中で最も値の大きい実績消費電力724を利用してもよい。また、該当する更新案件のアップデートが完了した他の車両200の実績消費電力724を利用するのではなく、これからアップデートを実行する車両200が過去に別の更新案件でアップデートした時の実績消費電力724を利用することで、実行判断閾値714を算出してもよい。なお、ステップS1602による位置情報を用いたレコードの抽出処理、およびステップS1603による通信速度を用いたレコードの抽出処理は、どちらか一方のみを実行するようにしてもよい。
上述した実施形態によれば、第1の実施形態で説明した(1)、(3)と同様の作用効果に加えて、次の作用効果が得られる。
(4)テレマティクスセンタ100の中央演算処理装置110は、車両200の中央演算処理装置211により取得されるテレマティクスセンタ100と車両200との間の通信速度に関する情報と、電力量に関する情報とに基づいて、電力量の閾値を変更する。このようにしたので、通信速度も加味して更新に要する電力量の閾値を変更することができる。
(5)テレマティクスセンタ100の中央演算処理装置110は、車両200の中央演算処理装置211により取得される車両200の位置に関する情報と、電力量に関する情報とに基づいて、電力量の閾値を変更する。このようにしたので、位置情報も加味して更新に要する電力量の閾値を変更することができる。
たとえばビルの陰に駐車している車両200は、受信する電波の電界強度が低く、更新プログラムを受信しづらい環境である。受信電波の電界強度が低い場所での更新プログラムの受信は時間を要するので、基準とする電界強度よりも低い電界強度ではプログラム更新に要する電力量閾値を大きくする補正を行う。
(第3の実施形態)
図13に、本発明の第3の実施形態に係るソフトウェア更新システムによる処理の一例を示す。第3の実施形態に係るソフトウェア更新システムは、図1に示す第1の実施形態に係るソフトウェア更新システムと同様の構成を有している。また、特に説明しない点については、第1の実施形態と同様である。第3の実施形態では、更新条件変更部115による実行判断閾値714を変更する処理が、第1の実施形態と異なる。
図13において、テレマティクスセンタ100の更新条件変更部115は、対象台数715が完了台数716と一致しない、すなわち全車両の更新が完了していない案件の更新案件ID710を1件抽出する(S1700)。更新条件変更部115は、抽出した更新案件ID710を用いて、同一のIDを持つ更新案件ID700のレコードを検索し、アップデート対象としているECUのECUID701を1つ以上抽出する(S1701)。そして、更新条件変更部115は、ECU毎に必要な消費電力量を推定するべく、消費電力ログ情報727に抽出したECUID701が含まれるレコードを検索し、ECUIDと実績消費電力量のペア情報を抽出する(S1702)。このとき、ステップS1700で抽出した更新案件ID710と、該当レコードの更新案件ID720が一致するかは問わない。
更新条件変更部115は、ECUID毎に抽出した実績消費電力量の情報から、ECUID毎に更新処理に必要な電力量の分布を作成する(S1703)。そして、更新条件変更部115は、各ECUIDの消費電力量の分布から、「該当するECUIDを持つECUのソフトウェア更新に必要であった電力量(消費電力量)がその値以下である」車両の割合が、各グループの更新済みの車両に対してA%以上となるような電力量の値E1、E2、・・・をそれぞれ算出する(S1704)。電力量の値は、ステップS1700で抽出した更新案件ID710が更新対象とするECUの数だけ算出される。なお、ECUの種別に応じて、基準となるA%の値を個別に変更してもよい。
更新条件変更部115は、算出したE1、E2、・・・の合計値ETを更新実行判断の閾値として算出し、更新案件に紐付く更新案件ID710のレコードにある実行判断閾値714を変更する(S1705)。そして、更新条件変更部115は、対象台数715が完了台数716と一致しない、すなわちまだ全車両の更新が完了していない案件の更新案件ID710全てについて、実行判断閾値714の変更が完了したか否かを確認する(S1706)。更新条件変更部115は、全ての更新案件に対して閾値の変更が完了した場合(S1706:Yes)は、図13に示す処理を終了する。更新条件変更部115は、閾値の変更が完了していない他の更新案件が存在する場合(S1706:No)は、全ての更新案件の閾値の変更が完了するまで、ステップS1700〜ステップS1705の処理を繰り返し実行する。
上述した実施形態によれば、第1の実施形態で説明した(1)、(3)と同様の作用効果に加えて、次の作用効果が得られる。
(6)車両200は複数のECU220,230,240,250を搭載している。車両200が有する複数のECU220,230,240,250の各々のソフトウェアの更新に要した電力量は個別に演算され、これらの電力量閾値は、たとえば携帯端末300に表示される。携帯端末300には車両200の残電力量も表示される。したがって、ユーザは更新対象であるECU220,230,240,250ごとの電力量閾値と残電力量とを参照して、ECUごとにソフトウェアを変更させることができる。
次のような変形も本発明の範囲内であり、変形例の一つ、もしくは複数を上述の実施形
態と組み合わせることも可能である。
(変形例1)
上述した実施形態および変形例では、実行判断可否に用いる消費電力量の閾値を、過去の実績を用いて算出する例を説明したが、過去の実績を用いて、更新に必要とされる更新時間の閾値を算出するようにしてもよい。また、例えば、ステップS1003〜ステップS1004のユーザ許諾取得の際の判断基準として、算出した更新時間の閾値をユーザに提示するようにしてもよい。算出した更新時間の閾値をテレマティクスセンタ100の入出力装置130に表示するようにしてもよい。なお、算出した消費電力量の閾値と併せて、更新時間の閾値をユーザに提示するようにしてもよい。ユーザは、携帯端末300に表示される更新時間の閾値を確認して、ソフトウェアの更新に関する処理の実行可否を判断することができる。
上記では、種々の実施の形態および変形例を説明したが、本発明はこれらの内容に限定されるものではない。本発明の技術的思想の範囲内で考えられるその他の態様も本発明の範囲内に含まれる。