JP2017134506A - ソフトウェア更新システム、サーバ - Google Patents

Abstract

【課題】消費電力の実績値に基づいてソフトウェア更新の実行判断の基準となる残電力量の閾値を決定することができるソフトウェア更新システムを提供する。
【解決手段】ソフトウェア更新システムは、車両に搭載される制御装置と、前記制御装置とネットワークを介して通信を行うサーバとを備え、前記制御装置のソフトウェアの更新を管理するソフトウェア更新システムであって、前記サーバは、少なくとも、前記制御装置が前記ソフトウェアを更新する際に要した電力量に関する情報に基づいて、前記ソフトウェアの更新の実行可否を判断する電力量閾値を演算して出力する閾値演算制御部を備え、前記制御装置は、前記サーバが電力量閾値を出力した後に受信したソフトウェア更新指令にしたがってソフトウェア更新処理を実行する。
【選択図】図１

Description

本発明は、ソフトウェア更新システムおよびサーバに関する。

近年、運転支援機能や自動運転技術の進展により、自動車用の電子制御装置（ＥＣＵ：Ｅｌｅｃｔｒｉｃ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）に搭載されるソフトウェアの規模が増大している。また、それに伴って、ソフトウェア不具合に起因するリコールの回数およびリコール１回あたりに対応が必要な台数規模が増加している。また、通信ネットワークの進展に伴って、自動車が無線でセンタシステム等とつながるコネクテッドカーが普及の兆しを見せている。このような状況のなか、従来携帯電話やテレビに使われていた無線での遠隔ソフト更新技術を自動車に適用し、自動車のＥＣＵソフトウェアを遠隔で更新する自動車向け遠隔ソフト更新技術へのニーズが高まっている。

例えば、特許文献１には、遠隔でＥＣＵのソフトウェアを更新するＯＴＡ（Ｏｖｅｒ ｔｈｅ Ａｉｒ）ソフトウェア更新システムが開示されている。特許文献１では、更新対象の自動車に搭載されるＥＣＵのハードウェアリソースを考慮し、より正確に更新に要する時間を算出してドライバーに提示する技術が開示されている。更新の実行時間が正確になる程、その更新に必要となる電力量も正確に算出できるため、自動車に搭載される蓄電池の残電力量が少ない場合には、更新を実行しないという判断も行うことができる。

特開２０１１−７０３０７号公報

特許文献１に記載の技術では、ソフトウェア更新に失敗してロールバック処理を実行する場合を考慮しておらず、算出した実行時間および予測される消費電力量の範疇内でソフトウェア更新処理を完了できない恐れがある。

本発明の第１の態様によるソフトウェア更新システムは、車両に搭載される制御装置と、制御装置とネットワークを介して通信を行うサーバとを備え、制御装置のソフトウェアの更新を管理するソフトウェア更新システムである。サーバは、少なくとも、制御装置がソフトウェアを更新する際に要した電力量に関する情報に基づいて、ソフトウェアの更新の実行可否を判断する電力量閾値を演算して出力する閾値演算制御部を備える。制御装置は、サーバが電力量閾値を出力した後に受信したソフトウェア更新指令にしたがってソフトウェア更新処理を実行する。
本発明の第２の態様によるサーバは、車両が有する制御装置のソフトウェアの更新を管理するサーバである。制御装置から送信される電力量に関する情報に基づいて、ソフトウェアの更新の実行可否を判断する電力量閾値を演算する閾値演算制御部と、制御装置から送信される電力量に関する情報を受信し、閾値演算制御部で演算された電力量閾値を制御装置に送信する通信部とを備える。

本発明によれば、制御装置がソフトウェアを更新する際に要した電力量に基づいて、ソフトウェア更新の実行判断の基準となる電力量閾値を演算する。したがって、更新実行可否を判断する際の基準をユーザに提供できる。たとえば、電力量閾値が車両バッテリの残電力量より大きいときは更新処理を許可せず、更新途中で更新処理が中断されることが回避される。

第１の実施形態に係るソフトウェア更新システムの構成例を示す図である。 第１の実施形態に係るテレマティクスセンタの各データベースに格納されるデータの構造を表すテーブルの一例を示す図である。 第１の実施形態に係るテレマティクスセンタの更新案件ＤＢに格納されるデータの構造を表すテーブルの一例を示す図である。 第１の実施形態に係るソフトウェア更新システムにおいて実行されるソフトウェア更新案件の登録からユーザ許諾までの処理の一例を示す図である。 第１の実施形態に係るソフトウェア更新システムにおいて実行されるソフトウェアのダウンロードに関する処理の一例を示す図である。 第１の実施形態に係るソフトウェア更新システムにおいて実行されるソフトウェアのインストールに関する処理の一例を示す図である。 第１の実施形態に係るソフトウェア更新システムにおいて実行されるソフトウェア更新処理の一例を示す図である。 第１の実施形態に係るソフトウェア更新システムにおいて実行される閾値変更処理の一例を示す図である。 第１の実施形態に係るテレマティクスセンタの入出力装置に表示される画面の一例を示す図である。 第１の実施形態に係る携帯端末の入出力装置に表示される画面の一例を示す図である。 第２の実施形態に係るソフトウェア更新システムにおいて実行されるソフトウェアのダウンロードおよびインストールに関する処理の一例を示す図である。 第２の実施形態に係るソフトウェア更新システムにおいて実行される閾値変更処理の一例を示す図である。 第３の実施形態に係るソフトウェア更新システムにおいて実行される閾値変更処理の一例を示す図である。

以下では、図１〜図１３を参照しながら、本発明の実施形態を説明する。

（第１の実施形態）
図１は、本発明の第１の実施形態に係るソフトウェア更新システムの構成例を示す図である。

図１に示す通り、本発明の第１の実施形態に係るソフトウェア更新システムは、テレマティクスセンタ１００と、車両２００と、携帯端末３００と、テレマティクスセンタ１００と車両２００の間で通信を可能とするネットワーク４００と、テレマティクスセンタ１００と携帯端末３００の間で通信を可能とするネットワーク５００とを有する。

テレマティクスセンタ１００は、車両２００の所有者であるユーザからソフトウェア適用の許諾を取得し、車両２００に搭載されるＥＣＵの更新ソフトウェアを配信する。テレマティクスセンタ１００は、ＥＣＵのソフトウェアの更新を管理するサーバである。車両２００は、ソフトウェアの遠隔更新装置であるソフトウェア更新装置２１０を含んで構成される。携帯端末３００は、ユーザの操作により、ソフトウェア更新の許諾結果をテレマティクスセンタ１００に送信する。

ネットワーク４００およびネットワーク５００としては、例えば携帯電話網、インターネット網、無線ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）等の近距離無線通信網、あるいはそれら複数の通信網の組み合わせで構成されたものなどが挙げられる。なお、ネットワーク４００およびネットワーク５００は、共通のネットワークであってもよい。

図１では、テレマティクスセンタ１００に接続される車両２００および携帯端末３００をそれぞれ１台ずつのみ示しているが、これらは１台に限定するものではない。以下の説明では、複数の車両２００がテレマティクスセンタ１００に接続されるものとする。

テレマティクスセンタ１００は、中央演算処理装置１１０と、記憶装置１２０と、入出力装置１３０と、通信部１４０とから構成される。入出力装置１３０は、タッチパネルやキーボード、マウスなどの組み合わせから構成され、入力部および表示部として機能する。

中央演算処理装置１１０は、例えばＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）やＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）などのプロセッサ、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）などから構成される。中央演算処理装置１１０は、これらを用いて所定の動作プログラムを実行することで、テレマティクスセンタ１００の各種機能を実現するための処理を行う。中央演算処理装置１１０は、その機能として、更新案件管理部１１１、紐付情報管理部１１２、ユーザ許諾取得部１１３、更新データ配信部１１４、更新条件変更部１１５などを有する。

更新案件管理部１１１は、リコールなどのソフトウェア更新を要する事象を一意に管理する。紐付情報管理部１１２は、車両２００の所有車であるユーザを一意に特定する。ユーザ許諾取得部１１３は、携帯端末３００を介して、ユーザからソフトウェア更新の実行許諾を取得する。更新データ配信部１１４は、ソフトウェア更新のための新しいソフトウェアを車両２００に配信する。更新条件変更部１１５は、新しいソフトウェアをＥＣＵに適用するための条件を変更する。

記憶装置１２０は、例えば、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）、フラッシュメモリ、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）などから構成される。記憶装置１２０には、中央演算処理装置１１０が実行するプログラムや、プログラムの実行に必要なデータ群などが格納される。記憶装置１２０に格納されるデータ群には、更新案件ＤＢ１２１、車両構成ＤＢ１２２、ユーザ車両紐付ＤＢ１２３、ソフトウェア管理ＤＢ１２４などが含まれる。

更新案件ＤＢ１２１は、ソフトウェア更新案件の情報を蓄積する。車両構成ＤＢ１２２は、販売された車両２００にどのようなＥＣＵが搭載されているか等、車両の構成情報を蓄積する。ユーザ車両紐付ＤＢ１２３は、ユーザと車両２００の紐付情報を蓄積する。ユーザと車両２００の紐付情報は、どのユーザがどの車両２００を保有しているかの関係を示す情報である。ソフトウェア管理ＤＢ１２４は、車両２００に配信するソフトウェアを蓄積する。なお、ソフトウェア管理ＤＢ１２４には、テレマティクスセンタ１００が構築された環境のオペレーティングシステムに付属するファイルシステムなどを利用してもよい。

通信部１４０は、ネットワーク４００およびネットワーク５００で用いられる通信規格に準拠したネットワークカードなどから構成される。ネットワークカードは、例えば、有線ＬＡＮなどの有線通信や無線ＬＡＮなどの無線通信、あるいはその両方に必要な通信規格に準拠する。通信部１４０は、ネットワーク４００、５００をそれぞれ介して、車両２００および携帯端末３００と各種プロトコルに基づきデータを送受信する。

車両２００は、ソフトウェア更新装置２１０と、エンジンＥＣＵ２２０と、ＥＣＵ２３０およびＥＣＵ２４０と、電源管理ＥＣＵ２５０と、蓄電池（バッテリー）２６０と、位置測位装置２７０と、通信部２８０とから構成される。

エンジンＥＣＵ２２０は、車両２００のエンジンの動作を管理する。ＥＣＵ２３０およびＥＣＵ２４０は、本実施形態において、ソフトウェアの更新対象となるＥＣＵである。電源管理ＥＣＵ２５０は、車両２００の電源を管理する。蓄電池２６０は、鉛蓄電池などから構成され、鉛蓄電池などの電力を蓄積する。位置測位装置２７０は、ＧＰＳ（Ｇｒｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）や無線ＬＡＮなどを用いて測位を行い、車両２００の位置情報を取得する。各機器は、ＣＡＮ（Ｃｏｎｔｒｏｌｌｅｒ Ａｒｅａ Ｎｅｔｗｏｒｋ）などの車内ネットワークで接続される。

なお、各ＥＣＵには、自身を動作させるためのソフトウェアが内蔵されている。ＥＣＵ自身を動作させるためのソフトウェアは、各ＥＣＵが持つ記憶装置に格納されている。

なお、車両２００に搭載される、ソフトウェア遠隔更新が可能なＥＣＵは２つに限定するものでなく、１つであってもよく、任意の複数であってもよい。ソフトウェア更新装置２１０と位置測位装置２７０と通信部２８０とは、同一の機器であってもよいし、異なる機器であってもよい。また、ソフトウェア更新装置２１０は、車両２００とは別の独立した電子機器であってもよい。具体的には、自動車に搭載されるＰＮＤ（Ｐｏｒｔａｂｌｅ Ｎａｖｉｇａｔｉｏｎ Ｄｅｖｉｃｅ）、スマートフォン、ドライブレコーダや、携帯端末を自動車に固定するためのクレードルなど、それらの組み合わせにて構成されることが考えられる。これらの端末は、例えばＯＢＤ（Ｏｎ Ｂｏａｒｄ Ｄｉａｇｎｏｓｔｉｃｓ）などのコネクタを用いることで、エンジンＥＣＵ２２０、ソフトウェア更新対象のＥＣＵ２３０およびＥＣＵ２４０、電源管理ＥＣＵ２５０などとデータを送受信することが考えられる。

ソフトウェア更新装置２１０は、中央演算処理装置２１１および記憶装置２１５から構成される。中央演算処理装置２１１は、例えばＣＰＵやＦＰＧＡなどのプロセッサ、ＲＡＭなどから構成され、これらを用いて所定の動作プログラムを実行することで、車両２００の各種機能を実現する処理を行う。中央演算処理装置２１１は、その機能として、更新案件確認部２１２、更新データ要求部２１３、ソフトウェア更新部２１４などを有する。

更新案件確認部２１２は、ソフトウェア更新が必要な案件があるか否かを、テレマティクスセンタ１００に問い合わせる。更新データ要求部２１３は、ソフトウェア更新案件があった場合に、新しいソフトウェアやアップデート実行要件を更新データとして、テレマティクスセンタ１００に要求する。ソフトウェア更新部２１４は、受信したソフトウェアおよびアップデート実行要件に基づいてＥＣＵのソフトウェアを更新し、その実行結果をテレマティクスセンタ１００に送信する。

記憶装置２１５は、例えば、ＨＤＤ、ＳＳＤ、フラッシュメモリ、ＲＯＭなどから構成される。記憶装置２１５には、中央演算処理装置２１１が実行するプログラム、プログラムの実行に必要なデータ群などが格納される。記憶装置２１５には、ソフトウェア更新のための新しいソフトウェアが格納される。

通信部２８０は、ネットワーク４００で用いられる通信規格に準拠したネットワークカードなどから構成される。ネットワークカードは、例えば、有線通信や無線通信、あるいはその両方に必要な通信規格に準拠する。通信部２８０は、ネットワーク４００を介して、テレマティクスセンタ１００と各種プロトコルに基づきデータを送受信する。

携帯端末３００は、中央演算処理装置３１０と、記憶装置３２０と、入出力装置３３０と、通信部３４０とから構成される。入出力装置３３０は、タッチパネルやキーボード、マウスなどの組み合わせから構成され、入力部および表示部として機能する。

中央演算処理装置３１０は、例えばＣＰＵやＦＰＧＡなどのプロセッサ、ＲＡＭなどから構成され、所定の動作プログラムを実行することで、携帯端末３００の各種機能を実現する処理を行う。中央演算処理装置３１０は、その機能として、更新情報表示部３１１、許諾結果送信部３１２などを有する。

更新情報表示部３１１は、テレマティクスセンタ１００から送信されるソフトウェア更新に関する情報を受信し、入出力装置３３０に表示させる。許諾結果送信部３１２は、入出力装置３３０を介して取得したユーザ許諾情報を、テレマティクスセンタ１００に送信する。

記憶装置３２０は、例えば、ＨＤＤ、ＳＳＤ、フラッシュメモリ、ＲＯＭなどから構成され、中央演算処理装置３１０が実行するプログラム、およびプログラムの実行に必要なデータ群などが格納される。

通信部３４０は、ネットワーク５００で用いられる通信規格に準拠したネットワークカードなどから構成される。ネットワークカードは、例えば、有線通信や無線通信、あるいはその両方に必要な通信規格に準拠する。通信部３４０は、ネットワーク５００を介して、テレマティクスセンタ１００と各種プロトコルに基づきデータを送受信する。

図２は、本発明の第１の実施形態において、テレマティクスセンタ１００の車両構成ＤＢ１２２、ユーザ車両紐付ＤＢ１２３の各データベース（ＤＢ）に格納されるデータの構造を表すテーブルの一例を示す図である。図２（ａ）は車両構成ＤＢ１２２に格納されるテーブル例を示し、図２（ｂ）はユーザ車両紐付ＤＢ１２３に格納されるテーブル例を示す。

図２（ａ）において、車両構成ＤＢ１２２には、ＶＩＮ（Ｖｅｈｉｃｌｅ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ Ｎｕｍｂｅｒ）６００、車種ＩＤ６０１、ＥＣＵＩＤ６０２、ソフトウェアバージョン６０３などの各データが格納される。ＶＩＮ６００は、車両２００を一意に特定可能な識別子である。車種ＩＤ６０１は、そのＶＩＮ６００を持つ車両２００の車種を一意に特定可能な識別子である。ＥＣＵＩＤ６０２は、そのＶＩＮ６００を持つ車両２００に搭載されるＥＣＵを一意に特定可能な識別子である。ソフトウェアバージョン６０３は、ＥＣＵに搭載されているソフトウェアのバージョン情報を一意に特定可能な識別子である。

図２（ｂ）において、ユーザ車両紐付ＤＢ１２３には、ＶＩＮ６１０、ユーザＩＤ６１１、メールアドレス６１２などの各データが格納される。ユーザＩＤ６１１は、ユーザを一意に特定可能な識別子である。メールアドレス６１２は、ユーザＩＤ６１１に紐付くユーザの携帯端末３００に、ソフトウェアの更新情報を配信するために用いられる。

図３は、本発明の第１の実施形態において、テレマティクスセンタ１００の更新案件ＤＢ１２１に格納されるデータの構造を表すテーブルの一例を示す図である。図３（ａ）、図３（ｂ）、図３（ｃ）は、それぞれ更新案件ＤＢ１２１に格納される第１のテーブルの一例、第２のテーブルの一例、第３のテーブルの一例を示す図である。

図３（ａ）において、更新案件ＤＢ１２１の第１のテーブルは、更新案件ＩＤ７００、ＥＣＵＩＤ７０１、ファイル名７０２、更新方式７０３、適用バージョン７０４、依存関係７０５などから構成される。更新案件ＩＤ７００は、リコールなどの複数車両を対象としたソフトウェアアップデートを要する案件を一意に特定可能な識別子である。ＥＣＵＩＤ７０１は、その更新案件がアップデート対象とするＥＣＵの識別子を示す。ファイル名７０２は、アップデート対象のＥＣＵに適用する新しいソフトウェアの所在を示す。更新方式７０３は、新しいソフトウェアがどのような形態で作成されたかを示す。適用バージョン７０４は、新しいソフトウェアを適用してアップデートされた後のソフトウェアバージョンを示す。依存関係７０５は、複数のＥＣＵを同時に更新する案件の場合に、複数のＥＣＵ間にソフトウェアの依存関係が存在するか否かを示す。

図３（ｂ）において、更新案件ＤＢ１２１の第２のテーブルは、更新案件ＩＤ７１０、車種ＩＤ７１１、更新時間７１２、予想消費電力７１３、実行判断閾値７１４、対象台数７１５、完了台数７１６などから構成される。車種ＩＤ７１１は、その更新案件が対象とするＥＣＵを搭載する車種の識別子を示す。更新時間７１２および予想消費電力７１３は、更新案件によるアップデートに要する予想更新時間および予想消費電力を示す。実行判断閾値７１４は、更新案件に基づくアップデートの実行可否を判断する基準である、蓄電池２６０の残電力量の閾値を示す。対象台数７１５は、この更新案件が対象とする車両２００の全台数を示す。完了台数７１６は、既にアップデートが完了した車両２００の台数を示す。

図３（ｃ）において、更新案件ＤＢ１２１の第３のテーブルは、更新案件ＩＤ７２０、ＶＩＮ７２１、ユーザ許諾７２２、更新日時７２３、実績消費電力７２４、ファイル伝送速度（ソフトウェア伝送速度）７２５、ロールバック実行回数７２６、消費電力ログ情報７２７、更新実行位置７２８などから構成される。

図３（ｃ）において、ＶＩＮ７２１は、その案件が対象とする車両２００の識別子を示す。ユーザ許諾７２２は、対象の車両２００の所有車であるユーザからアップデート実行の許諾を取得済みであるかを示す。更新日時７２３は、アップデートが完了した場合に、アップデート実行日時を格納する。実績消費電力７２４は、アップデートに要した消費電力の実績値を示す。ファイル伝送速度７２５は、新しいソフトウェアのダウンロードに成功した場合のファイル伝送速度を示す。ロールバック実行回数７２６は、アップデート時にロールバック処理を実行したか否か、ロールバック処理を実行した場合は何回ロールバックを実行したかを示す。消費電力ログ情報７２７は、アップデート実行時にＥＣＵ毎やステップ毎などで消費した電力量を示す。更新実行位置７２８は、アップデートを実行した時の車両２００の位置情報を示す。

図４は、本実施形態のソフトウェア更新システムにおけるソフトウェア更新案件の登録からユーザ許諾までの処理の一例を示す図である。図４に示す処理は、テレマティクスセンタ１００の更新案件管理部１１１、紐付情報管理部１１２およびユーザ許諾取得部１１３と、携帯端末３００の更新情報表示部３１１および許諾結果送信部３１２とでそれぞれ行われる。

図４において、テレマティクスセンタ１００の更新案件管理部１１１は、入出力装置１３０を介して、システム管理者からＥＣＵの更新案件の登録を受け付ける（Ｓ８００）。システム管理者とは、テレマティクスセンタ１００の運用者や、ＥＣＵの製造管理者などが考えられる。更新案件管理部１１１は、対象ＥＣＵＩＤ、アップデートファイル、更新方式、新しいバージョン、および複数ＥＣＵを更新する場合はその依存関係に関する情報をそれぞれ受け付ける。更新案件管理部１１１は、新しく更新案件ＩＤ７００を生成した後に、更新案件ＤＢ１２１のＥＣＵＩＤ７０１〜依存関係７０５に、受け付けた情報をそれぞれ蓄積する。このとき、更新案件管理部１１１は、対象となる車種、システム管理者等が予想する更新時間および消費電力と、更新実行の判断となる蓄電池２６０の残電力量の閾値に関する情報とを受け付ける。更新案件管理部１１１は、生成した更新案件ＩＤと共に、更新案件ＤＢ１２１の更新案件ＩＤ７１０〜実行判断閾値７１４に、それぞれの情報を蓄積する。

更新案件管理部１１１は、新しい更新案件を受け付けると、更新対象であるＥＣＵＩＤ７０１を持つ車両２００を車両構成ＤＢ１２２から検索する（Ｓ８０１）。更新案件管理部１１１は、該当する車両２００の台数を、更新案件ＤＢ１２１の対象台数７１５に蓄積する。また、更新案件管理部１１１は、該当する車両２００の全てのＶＩＮ６００を、生成した更新案件ＩＤと共に、更新案件ＤＢ１２１の更新案件ＩＤ７２０、ＶＩＮ７２１に蓄積する。

紐付情報管理部１１２は、更新案件として登録されたＶＩＮ７２１を持つ車両２００のユーザにソフトウェアの更新情報を送信するべく、ユーザ車両紐付ＤＢ１２３からユーザＩＤ６１１およびメールアドレス６１２を検索する（Ｓ８０２）。ユーザ許諾取得部１１３は、メールアドレス６１２のリストに対して、更新情報としてメールを送信する（Ｓ８０３）。

携帯端末３００の更新情報表示部３１１は、テレマティクスセンタ１００から更新情報を受信する（Ｓ８１０）。更新情報表示部３１１は、更新情報の内容とアップデート実行の許諾取得に関する情報を、入出力装置３３０に表示させる（Ｓ８１１）。携帯端末３００の許諾結果送信部３１２は、入出力装置３３０を介して得られたユーザの許諾選択結果を、テレマティクスセンタ１００に送信する（Ｓ８１２）。なお、例えばメールなどの通知方法では、ステップＳ８１０、ステップＳ８１１、ステップＳ８１２に時間を要することが考えられる。

テレマティクスセンタ１００のユーザ許諾取得部１１３は、携帯端末３００から許諾選択結果を受信する（Ｓ８０４）。ユーザ許諾取得部１１３は、送付元のメールアドレスを用いてユーザ車両紐付ＤＢ１２３を検索し、送付したユーザが所有するＶＩＮ６１０を特定する。ユーザ許諾取得部１１３は、さらに、ＶＩＮ６１０と同一のＶＩＮを示すＶＩＮ７２１を持つ更新案件ＤＢ１２１のレコードについて、ユーザ許諾７２２を更新する。

図５は、本実施形態のソフトウェア更新システムにおけるソフトウェアのダウンロードに関する処理の一例を示す図である。図５に示す処理は、車両２００の更新案件確認部２１２および更新データ要求部２１３と、テレマティクスセンタ１００の更新案件管理部１１１とでそれぞれ行われる。

図５において、車両２００の更新案件確認部２１２は、エンジンＥＣＵ２２０からの情報を用いてエンジン始動を検知する（Ｓ９００）。更新案件確認部２１２は、エンジン始動を検知すると、まだ完了していない更新案件が存在するか否かを確認するため、テレマティクスセンタ１００に対して問い合わせを実行する（Ｓ９０１）。

テレマティクスセンタ１００の更新案件管理部１１１は、車両２００から更新案件の問い合わせを受信する（Ｓ９１０）。更新案件管理部１１１は、問い合わせ元の車両２００のＶＩＮが、更新案件ＤＢ１２１のＶＩＮ７２１に登録されているか否かを確認する（Ｓ９１１）。ＶＩＮが登録されていた場合には、更新案件管理部１１１は、該当するレコードのユーザ許諾７２２を確認し、既にユーザ許諾を取得済みであるか否かを確認する（Ｓ９１３）。そして、更新案件管理部１１１は、ＶＩＮが登録されているか否か及びユーザ許諾を取得済みであるか否かの、２つの確認結果を車両２００に送信する（Ｓ９１４）。

車両２００の更新案件確認部２１２は、テレマティクスセンタ１００から更新案件の確認結果を受信する（Ｓ９０２）。更新案件確認部２１２は、更新案件がありかつユーザ許諾が得られている場合には、更新データ要求部２１３を用いて、更新対象ＥＣＵの新しいソフトウェアと更新実行要件をテレマティクスセンタ１００に要求する（Ｓ９０３）。更新実行要件は、更新実行の判断基準となる残電力量の閾値に関する情報などである。

テレマティクスセンタ１００の更新案件管理部１１１は、車両２００からソフトウェアダウンロードの要求を受信する（Ｓ９１５）。更新案件管理部１１１は、問い合わせ元の車両２００のＶＩＮが、更新案件ＤＢ１２１のＶＩＮ７２１に登録されているか否かを確認する。ＶＩＮが登録されていた場合には、更新案件管理部１１１は、該当レコードの更新案件ＩＤ７２０を用いて更新案件ＤＢ１２１の更新案件ＩＤ７００を含むテーブルを検索することで、ソフトウェアアップデートに必要なファイル名７０２を抽出する。更新案件管理部１１１は、さらに、更新案件ＩＤ７２０を用いて更新案件ＤＢ１２１の更新案件ＩＤ７１０を検索して、更新時間７１２〜実行判断閾値７１４を抽出する。そして、更新案件管理部１１１は、対象のファイル名７０２を用いて更新用ソフトウェアを抽出する。更新案件管理部１１１は、更新用ソフトウェアおよび更新実行要件としての更新時間７１２〜実行判断閾値７１４に関する情報を、車両２００に送信する（Ｓ９１６）。

車両２００の更新データ要求部２１３は、テレマティクスセンタ１００から新しいソフトウェアと更新実行要件を受信する（Ｓ９０４）。更新データ要求部２１３は、それらのデータを記憶装置２１５に蓄積する（Ｓ９０５）。なお、更新案件がない、あるいはユーザ許諾がまだ得られていない場合には、ステップＳ９０３からステップＳ９０５は実行されない。

図６は、本実施形態のソフトウェア更新システムにおけるソフトウェアのインストールに関する処理の一例を示す図である。図６に示す処理は、車両２００のソフトウェア更新部２１４と、テレマティクスセンタ１００の更新案件管理部１１１、紐付情報管理部１１２およびユーザ許諾取得部１１３と、携帯端末３００の更新情報表示部３１１とでそれぞれ行われる。

車両２００のソフトウェア更新部２１４は、エンジンＥＣＵ２２０からの情報を用いて、エンジン停止を検知する（Ｓ１０００）。ソフトウェア更新部２１４は、エンジン停止を検知すると、電源管理ＥＣＵ２５０を介して蓄電池２６０の残電力量を確認する（Ｓ１００１）。ソフトウェア更新部２１４は、記憶装置２１５に新しいソフトウェアが蓄積されているか否か、および、蓄電池２６０の残電力量がソフトウェアの更新実行要件である残電力量の閾値を上回っているか否かを確認する（Ｓ１００２）。ソフトウェア更新部２１４は、新しいソフトウェアが格納されており、かつ残電力量が閾値を上回っている場合（Ｓ１００２：Ｙｅｓ）には、テレマティクスセンタ１００にアップデートを開始できることを示す情報を送信する（Ｓ１００３）。

テレマティクスセンタ１００の更新案件管理部１１１は、車両２００からアップデートの実行可能を示す情報を受信すると、車両２００の更新案件に対応する更新案件ＩＤ７１０のレコードから、更新時間７１２〜実行判断閾値７１４の情報を検索する。更新案件管理部１１１は、図４に示すステップＳ８０２〜ステップＳ８０３と同様の方法で、ユーザが所有する携帯端末３００に対して、更新情報と共にアップデート開始に関する情報を通知する（Ｓ１０１０）。アップデート開始に関する情報には、例えば、更新時間７１２〜実行判断閾値７１４の情報が含まれる。

携帯端末３００の更新情報表示部３１１は、テレマティクスセンタ１００からアップデートの開始情報を受信すると、アップデートに要する時間や消費電力などの情報を、入出力装置３３０に表示させる（Ｓ１０２０）。そして、許諾結果送信部３１２は、入出力装置３３０を介してユーザからのアップデート実行に対する許諾を取得し、テレマティクスセンタ１００に送信する（Ｓ１０２１）。

テレマティクスセンタ１００は、携帯端末３００からのアップデート実行許諾を取得すると、ステップＳ８０４と同様の手順で、発信元メールアドレスからユーザが所有する車両２００のＶＩＮを特定する。テレマティクスセンタ１００は、さらに、該当する車両２００に対して、許諾情報を転送する（Ｓ１０１１）。

車両２００のソフトウェア更新部２１４は、テレマティクスセンタ１００から許諾情報を受信する（Ｓ１００４）。ソフトウェア更新部２１４は、記憶装置２１５に蓄積された新しいソフトウェアを用いて、対象ＥＣＵのソフトウェア更新処理を実行する（Ｓ１００５）。なお、このステップＳ１００５で行われる処理の詳細については、図７を用いて後述する。そして、ソフトウェア更新部２１４は、アップデートが完了した後、その実行結果として、更新日時、実消費電力、ロールバック実行回数、車両２００の位置情報などを、テレマティクスセンタ１００に送信する（Ｓ１００６）。

テレマティクスセンタ１００の更新案件管理部１１１は、車両２００からアップデートの実行結果を受信すると、車両２００のＶＩＮから更新案件ＤＢ１２１のＶＩＮ７２１を検索する。更新案件管理部１１１は、検索されたＶＩＮ７２１のレコードの更新日時７２３〜更新実行位置７２８を更新する。また、更新案件管理部１１１は、該当レコードの更新案件ＩＤ７２０と同一のＩＤを持つ更新案件ＩＤ７１０について、完了台数７１６に１を加えて更新する。更新案件管理部１１１は、さらに、図４に示すステップＳ８０２〜ステップＳ８０３と同様の方法で、ユーザが所有する携帯端末３００に対して、実行結果情報と共にアップデート完了を通知する（Ｓ１０１２）。

携帯端末３００の更新情報表示部３１１は、テレマティクスセンタ１００から実行結果情報を受信すると、アップデートの実行結果を入出力装置３３０に表示させる（Ｓ１０２２）。

新しいソフトウェアが格納されていない、あるいは残電力量が閾値を上回っていない場合（Ｓ１００２：Ｎｏ）、更新を実行しなかったという結果を携帯端末３００に送信するため、ステップＳ１００６、ステップＳ１０１２、ステップＳ１０２２の処理を行う。なお、ＥＣＵのソフトウェアの更新を実行しなかった場合には、ステップＳ１０２２の処理は実行しなくともよい。

図７は、本実施形態のソフトウェア更新システムにおいて、図６のステップＳ１００５で実行される処理の一例を示す図である。図７に示す処理は、ソフトウェア更新装置２１０と更新対象のＥＣＵとでそれぞれ行われる。ここでは、代表的にＥＣＵ２３０をソフトウェアの更新対象としたシーケンスを示す。

図７において、ソフトウェア更新装置２１０のソフトウェア更新部２１４は、車内ネットワークを介して、ＥＣＵ２３０にバージョン情報の取得要求を送信する（Ｓ１１００）。ＥＣＵ２３０は、ソフトウェア更新装置２１０からバージョン取得要求を受信する（Ｓ１１１０）。ＥＣＵ２３０は、自身のソフトウェアバージョンを示す情報を、ソフトウェア更新装置２１０に送信する（Ｓ１１１１）。ソフトウェア更新部２１４は、ＥＣＵ２３０からバージョン情報を受信する（Ｓ１１０１）。ソフトウェア更新部２１４は、受信したバージョン情報が示すソフトウェアバージョンが、更新用のソフトウェアのバージョンよりも古いことを確認し、更新対象のソフトウェアであることを特定する。

次に、ソフトウェア更新部２１４は、記憶装置２１５に蓄積したＥＣＵ２３０用の更新ソフトウェアが差分ファイル・圧縮ファイルであった場合には、ＥＣＵ２３０にそのデータを転送し、データを復元・解凍するよう要求を送信する（Ｓ１１０２）。ＥＣＵ２３０は、ソフトウェア更新装置２１０からデータ復元・解凍要求を受信する（Ｓ１１１２）。ＥＣＵ２３０は、受信したデータと自身の現在のソフトウェアを用いて更新後のデータを復元・解凍して、ＥＣＵ２３０の内部（ＥＣＵ２３０が有する記憶装置）に記憶する。ＥＣＵ２３０は、復元・解凍した結果を、ソフトウェア更新装置２１０に送信する（Ｓ１１１３）。

ソフトウェア更新装置２１０は、ＥＣＵ２３０から復元・解凍結果を受信する（Ｓ１１０３）。ソフトウェア更新装置２１０は、ＥＣＵ２３０に対して、ソフトウェアが格納されている記憶領域の一部分（Ｂｌｏｃｋ）を消去するよう指示する（Ｓ１１０４）。ＥＣＵ２３０は、ソフトウェア更新装置２１０から消去要求を受信する（Ｓ１１１４）。ＥＣＵ２３０は、記憶装置から該当領域のデータを消去し、その結果をソフトウェア更新装置２１０に送信する（Ｓ１１１５）。ソフトウェア更新装置２１０は、ＥＣＵ２３０から消去結果を受信する（Ｓ１１０５）。

ソフトウェア更新装置２１０は、ＥＣＵ２３０に対して、復元・解凍された新しいソフトウェアを利用して、Ｓ１１０４で消去を指示した記憶装置のＢｌｏｃｋに対して、新しいソフトウェアでの書き込みを命令する（Ｓ１１０６）。ＥＣＵ２３０は、ソフトウェア更新装置２１０から書き込み要求を受信する（Ｓ１１１６）。ＥＣＵ２３０は、記憶装置の該当ブロックを新しいソフトウェアの一部で書き込む。ＥＣＵ２３０は、さらに、書き込みが成功したかあるいは失敗したかの情報を、ソフトウェア更新装置２１０に送信する（Ｓ１１１７）。

ソフトウェア更新装置２１０は、ＥＣＵ２３０から書き込み結果を受信する（Ｓ１１０７）。ソフトウェア更新装置２１０は、書き込み結果が成功であるか否かを確認する（Ｓ１１０８）。ソフトウェア更新装置２１０は、書き込みに失敗したと判断した場合（Ｓ１１０８：Ｎｏ）には、再度書き込み処理を実行するべく、同一Ｂｌｏｃｋに対して再度ステップＳ１１０４〜ステップＳ１１０７を実行する。

ソフトウェア更新装置２１０は、書き込みに成功したと判断した場合（Ｓ１１０８：Ｙｅｓ）には、ＥＣＵ２３０の記憶装置の全てのＢｌｏｃｋの書き込みが終了したか否かを判断する（Ｓ１１０９）。全てのＢｌｏｃｋの書き込みが完了していない場合（Ｓ１１０９：Ｎｏ）には、ソフトウェア更新装置２１０は、前述とは異なるＢｌｏｃｋに対してステップＳ１１０４〜ステップＳ１１０７を行う。ソフトウェア更新装置２１０は、全てのＢｌｏｃｋの書き込みが完了するまで、ステップＳ１１０４〜ステップＳ１１０７の処理を繰り返す。

以上は、差分ファイルを圧縮したファイルを用いて、ソフトウェアを更新するシーケンス例を示しているが、更新案件ＤＢ１２１の更新方式７０３に格納される、ソフトウェアの更新方法に応じてその処理の取捨選択をしてもよい。例えば、差分も圧縮もしない完全なファイルを用いてソフトウェアを更新する場合には、ステップＳ１１０２〜ステップＳ１１０３は実行しなくともよい。

図８は、本実施形態のソフトウェア更新システムにおいて、テレマティクスセンタ１００の更新条件変更部１１５による処理の一例を示す図である。更新条件変更部１１５は、更新案件ＤＢ１２１の実行判断閾値７１４を変更する処理を実行する。この処理の実行タイミングは、１時間周期などの定期的なものであっても、該当する更新案件のレコードの対象台数７１５が一定台数増加する度であっても、テレマティクスセンタ１００の管理者が手動で実行するものであってもよい。また、図５のステップＳ９０１のアップデート情報の問い合わせ時に実行判断閾値７１４の変更処理を実行し、ステップＳ９１４の結果送信時に算出結果を送信するようにしてもよい。

図８において、テレマティクスセンタ１００の更新条件変更部１１５は、更新案件ＤＢ１２１から、対象台数７１５が完了台数７１６と一致しない、すなわち全車両の更新が完了していない案件の更新案件ＩＤ７１０を１件抽出する（Ｓ１２００）。

更新条件変更部１１５は、抽出した更新案件ＩＤ７１０を用いて、同一のＩＤを持つ更新案件ＩＤ７２０のレコードを全て検索し、その実績消費電力７２４およびロールバック実行回数７２６を収集する（Ｓ１２０１）。更新条件変更部１１５は、ロールバック実行回数７２６が０回であるレコードと、ロールバック実行回数７２６が１回以上であるレコードの２つにグループを分割する。更新条件変更部１１５は、さらに、２つのグループのレコード数を比較して、更新処理のロールバック発生確率ＰＲを算出する（Ｓ１２０２）。更新条件変更部１１５は、各グループのレコードに含まれる実績消費電力７２４の情報から、更新処理に必要な電力量の分布を作成する（Ｓ１２０３）。

次に、更新条件変更部１１５は、作成した２つのグループの分布から、電力量の値Ｔをそれぞれ算出する（Ｓ１２０４）。電力量の値Ｔは、例えば、ソフトウェア更新に必要であった電力量（消費電力量）がＴ以下である車両の割合が、各グループのソフトウェア更新済みの車両に対してＡ％以上となるような値である。ロールバックせずアップデート完了したグループの分布から算出した電力量の値をＴ１、アップデート時にロールバックが発生したグループの分布から算出した電力量の値をＴ２とする。更新条件変更部１１５は、ロールバック発生確率ＰＲと、算出したＴ１およびＴ２から、ソフトウェア更新時に必要となる可能性の高い電力量の期待値Ｅ、すなわち実行判断の閾値を算出する。そして、更新条件変更部１１５は、抽出した更新案件ＩＤ７１０のレコードの実行判断閾値７１４を変更する（Ｓ１２０５）。電力量の期待値Ｅは、例えば、次式にて算出される。
Ｅ＝Ｔ１×（１−ＰＲ）＋Ｔ２×ＰＲ

更新条件変更部１１５は、対象台数７１５が完了台数７１６と一致しない、すなわち全車両の更新が完了していない案件の更新案件ＩＤ７１０全てについて、実行判断閾値７１４の変更が完了したか否かを確認する（Ｓ１２０６）。

更新条件変更部１１５は、全ての更新案件に対して実行判断閾値７１４の変更が完了した場合（Ｓ１２０６：Ｙｅｓ）は、図８に示す処理を終了する。更新条件変更部１１５は、実行判断閾値７１４の変更が完了していない更新案件が存在する場合（Ｓ１２０６：Ｎｏ）は、ステップＳ１２００〜ステップＳ１２０５の処理を繰り返す。

なお、ステップＳ１２０５で変更する実行判断閾値７１４の値は、必ずしもステップＳ１２０４で算出する期待値Ｅでなくてもよい。実行判断閾値７１４の値は、例えば、電力量の値Ｔ１あるいはＴ２をそのまま利用することや、該当する更新案件の全車両のアップデート実績の中で最も値の大きい実績消費電力７２４を利用してもよい。また、該当する更新案件のアップデートが完了した他の車両２００の実績消費電力７２４を利用するのではなく、これからアップデートを実行する車両２００が過去に別の更新案件でアップデートした時の実績消費電力７２４を利用して、実行判断閾値７１４を算出してもよい。

図９に、本実施形態のソフトウェア更新システムにおいて、テレマティクスセンタ１００の入出力装置１３０に表示される画面の一例を示す。

図９において、テレマティクスセンタ１００の入出力装置１３０には、更新案件に関する情報を示す領域１３００、領域１３０１および領域１３０２が表示される。領域１３０１は、更新案件について、アップデート時にロールバックを実行しなかった車両２００の消費電力量の分布を表示するための画面領域である。領域１３０２は、アップデート時にロールバックを実行した車両２００の消費電力量の分布を表示するための画面領域である。

領域１３００では、更新案件ＤＢ１２１の更新案件ＩＤ７１０に紐付くレコードの車種ＩＤ７１１、更新時間７１２、対象台数７１５、完了台数７１６などの更新案件の詳細な情報が表示される。また、領域１３００には、更新案件についての実行判断閾値７１４の算出式と算出結果が表示される。さらに、領域１３００には、テレマティクスセンタ１００の管理者などにより、テレマティクスセンタ１００に対して実行判断閾値７１４の更新要求を行うための操作領域が表示される。テレマティクスセンタ１００の更新条件変更部１１５は、入出力装置１３０からの新しい閾値の入力に応じて、該当する更新案件の更新案件ＩＤ７１０のレコードの実行判断閾値７１４を更新する機能を有する。

領域１３０１は、ある更新案件の更新案件ＩＤ７２０を持つ全てのレコードの内、ロールバック実行回数７２６が０回であるレコードを対象に、横軸にアップデートに要した実際の消費電力である実績消費電力７２４を、縦軸にその車両２００の割合を示している。 図９に示す例では、図８のステップＳ１２０４におけるＡ％の値を、９０％と設定している。図９に示すように、ロールバックを実行せずアップデートが完了した車両の内、９０％の車両が４０Ｗｈ（ワットアワー）以下の消費電力、全ての車両が６１Ｗｈ以下の消費電力で更新処理を完了したことを示している。

領域１３０２は、ある更新案件の更新案件ＩＤ７２０を持つ全てのレコードの内、ロールバック実行回数７２６が１回以上であるレコードを対象に、横軸に実績消費電力７２４を、縦軸にその車両２００の割合を示している。図９に示すように、ロールバックを１回以上実行してアップデートを完了した車両の内、９０％の車両が８７Ｗｈ以下の消費電力、全ての車両が１０３Ｗｈ以下の消費電力で更新処理を実行できたことを示している。

図１０に、本実施形態のソフトウェア更新システムにおいて、携帯端末３００の入出力装置３３０に表示される画面の一例を示す。

図１０において、携帯端末３００の入出力装置３３０には、アップデート対象のＥＣＵがどのパーツに関するものかを可視化する領域１４００と、更新内容の詳細情報を示す領域１４０１と、ユーザから許諾を取得するための領域１４０２とが表示される。

図１０における画面は、ステップＳ８１１やステップＳ１０２０におけるユーザへの許諾取得に利用されるものであり、テレマティクスセンタ１００から送信されたメールを表示した画面を想定している。領域１４０１では、携帯端末３００のユーザが所有する車両２００のソフトウェア更新に関する情報として、更新案件ＤＢ１２１の車種ＩＤ７１１やＥＣＵＩＤ７０１、更新時間７１２などの情報が表示される。領域１４０２では、実行判断閾値７１４に関する情報、ユーザがアップデート実行の可否を選択する領域などが表示される。ユーザによる選択結果は、ステップＳ８１２およびステップＳ１０２１において、許諾結果送信部３１２からテレマティクスセンタ１００に送信される。

なお、本実施形態ではメールによるユーザへの通知方法を記載しているが、本発明はそれに限定するものではない。前述の通り、例えばソフトウェア更新装置２１０がＰＮＤなどの端末であり、入出力装置を持つ電子機器である場合には、携帯端末３００の入出力装置３３０の代わりにソフトウェア更新装置２１０の入出力装置にユーザ許諾などの画面を表示してもよい。
図１０の表示画面は一例であり、少なくとも、アップデート対象の電子機器とソフトウェアが特定できる表示と、アップデート実行要否の表示を有する画面であれば、その表示内容、表示項目、デザインなどは問わない。

また、ソフトウェア更新装置２１０と携帯端末３００は同一の機器であってもよい。この場合、ソフトウェア更新装置２１０がＰＮＤなどの端末であり、入出力装置を持つ電子機器である場合には、携帯端末３００の入出力装置３３０の代わりにソフトウェア更新装置２１０の入出力装置にユーザ許諾などの画面を表示してもよい。また、車両２００と携帯端末３００はテレマティクスセンタ１００を介さずに直接通信しても良く、さらにテレマティクスセンタ１００と携帯端末３００は同一の機器であってもよい。

上述した実施形態によれば、次の作用効果が得られる。
（１）実施形態のソフトウェア更新システムは、車両２００に搭載されるソフトウェア更新装置２１０とネットワーク４００を介して通信を行うテレマティクスセンタ１００とを備え、車両２００のＥＣＵ２２０〜２５０のソフトウェアの更新を管理する。テレマティクスセンタ１００は、少なくとも、ＥＣＵ２２０〜２５０がソフトウェアを更新する際に要した電力量に関する情報、すなわち実績消費電力に基づいて、ソフトウェアの更新の実行可否を判断する残電力量の閾値（電力量閾値）を演算して出力する中央演算処理装置（閾値演算制御部）１１０を備える。車両２００の中央演算処理装置２１１は、テレマティクスセンタ１００が残電力量の閾値を出力した後に受信したソフトウェア更新指令にしたがってソフトウェア更新処理を実行する。
実施形態では、テレマティクスセンタ１００の中央演算処理装置１１０から携帯端末３００に電力量閾値、残電力量などが表示され、ユーザはこの表示に基づいて更新実行の可否を決定する。ユーザが更新実行を指令すると、車両２００の中央演算処理装置２１１は、該当するＥＣＵのソフトウェアを更新する。
本実施形態では、ソフトウェア更新の際の実績消費電力を収集し、ソフトウェア更新の実行判断の基準となる残電力量の閾値を決定する。このようにしたので、最適な残電力量の閾値を決定することができる。この結果、不意な消費電力量の増加による更新失敗に備えつつ、不用意に閾値を厳しく設定することで、ソフトウェア更新の適用が進まないという状況を回避することができる。

（２）テレマティクスセンタ１００の中央演算処理装置１１０は、ソフトウェアの更新の際に実行したロールバック回数に関する情報と上記電力量に関する情報とに基づいて、電力量閾値を演算する。このようにしたので、ソフトウェアの更新の際に発生するロールバックを考慮して、更新に要する電力量の閾値を算出することができる。

（３）実施形態のソフトウェア更新システムは、テレマティクスセンタ１００の中央演算処理装置１１０から出力された電力量閾値を受信して表示部に表示する携帯端末３００をさらに含む。携帯端末３００には車両２００の残電力量も表示される。ユーザは、電力量閾値と残電力量とを比較してソフトウェアの更新の実行を判断することができ、ソフトウェア更新中に電力量が不足して更新が中断する不具合を防止することができる。

なお、特許文献１に記載の従来技術では、ソフトウェア更新時の車外環境（車内ネットワーク構成や通信速度など）を考慮しておらず、ハードウェア起因ではない原因で実行時間および消費電力量が増大する恐れがある。このようなケースで消費電力量が増加してしまった場合、アップデート中あるいはロールバック中にソフトウェア更新が中断されることになる。ソフトウェア更新が中断されて運転制御に関するＥＣＵのソフトウェア更新に失敗した場合には、次回運転時に自動車が操作できない可能性があり、容易にＥＣＵのソフトウェアを更新することができない。
一方で、ソフトウェア更新の実行判断の基準となる残電力量の閾値を厳しく設定（残電力量が９０％以上など）してしまうと、自動車の安全性に関わるソフトウェアアップデートの適用に時間が掛かってしまうという問題もある。
上記第１の実施形態のソフトウェア更新システムでは、このような問題が解決される。

（第２の実施形態）
図１１および図１２に、本発明の第２の実施形態に係るソフトウェア更新システムによる処理の一例を示す。第２の実施形態に係るソフトウェア更新システムは、図１に示す第１の実施形態に係るソフトウェア更新システムと同様の構成を有している。また、テレマティクスセンタ１００と携帯端末３００との間のユーザ許諾取得に関する処理は、図４に示す第１の実施形態の処理と同様である。

図１１は、第２の実施形態のソフトウェア更新システムにおけるソフトウェアのダウンロードおよびインストールに関する処理の一例を示す図である。図１１に示す処理は、車両２００の更新案件確認部２１２、更新データ要求部２１３およびソフトウェア更新部２１４と、テレマティクスセンタ１００の更新案件管理部１１１および更新条件変更部１１５と、携帯端末３００の更新情報表示部３１１および許諾結果送信部３１２とでそれぞれ行われる。図１１に示す例では、第１の実施形態の図５および図６に示す、更新ソフトウェアのダウンロードおよびインストール処理を一体化した処理を実現している。

車両２００の更新案件確認部２１２は、エンジンＥＣＵ２２０からの情報を用いて、エンジン停止を検知する（Ｓ１５００）。更新案件確認部２１２は、エンジン停止を検知すると、位置測位装置２７０から車両２００の現在位置を取得する。また、更新案件確認部２１２は、通信部２８０を用いて、テレマティクスセンタ１００との通信速度を測定する。更新案件確認部２１２は、現在位置および通信速度に関する情報と、まだ完了していない更新案件が存在するか否かを確認する問い合わせを、テレマティクスセンタ１００に送信する（Ｓ１５０１）。

テレマティクスセンタ１００の更新案件管理部１１１は、車両２００から更新案件の問い合わせを受信する（Ｓ１５１０）。更新案件管理部１１１は、問い合わせ元の車両２００のＶＩＮが、更新案件ＤＢ１２１のＶＩＮ７２１に登録されているか否かを確認する（Ｓ１５１１）。ＶＩＮが登録されていた場合には、更新案件管理部１１１は、該当するレコードのユーザ許諾７２２を確認し、既にユーザ許諾を取得済みであるか否かを確認する（Ｓ１５１２）。ユーザ許諾が取得済みであった場合には、更新案件管理部１１１は、該当レコードの更新案件ＩＤ７２０を用いて更新案件ＤＢ１２１の更新案件ＩＤ７１０を検索して、更新時間７１２および予想消費電力７１３に関する情報を抽出する。

更新条件変更部１１５は、アップデート実行の判断基準となる、残電力量の閾値を計算する（Ｓ１５１３）。ステップＳ１５１３で行われる処理の詳細については、図１２を用いて後述する。そして、更新案件管理部１１１は、ユーザ許諾の確認結果、更新時間７１２、予想消費電力７１３、およびステップＳ１５１３で算出した実行判断閾値７１４を、車両２００に送信する（Ｓ１５１４）。

車両２００の更新案件確認部２１２は、テレマティクスセンタ１００から更新案件の確認結果を受信する（Ｓ１５０２）。更新案件確認部２１２は、更新案件がありかつユーザから許諾が得られている場合には、蓄電池２６０の残電力量がソフトウェアの更新実行要件である残電力量の閾値を上回っているか否かを確認する（Ｓ１５０３）。

更新案件確認部２１２は、更新案件がありかつ残電力量が閾値を上回っている場合（Ｓ１５０４：Ｙｅｓ）には、更新データ要求部２１３を利用して、更新対象ＥＣＵの新しいソフトウェアのダウンロードを、テレマティクスセンタ１００に要求する（Ｓ１５０５）。

テレマティクスセンタ１００の更新案件管理部１１１は、車両２００からソフトウェアダウンロードの要求を受信する（Ｓ１５１５）。更新案件管理部１１１は、問い合わせ元の車両２００のＶＩＮが、更新案件ＤＢ１２１のＶＩＮ７２１に登録されているか否かを確認する。ＶＩＮが登録されていた場合には、更新案件管理部１１１は、該当レコードの更新案件ＩＤ７２０を用いて更新案件ＤＢ１２１の更新案件ＩＤ７００を含むテーブルを検索して、ソフトウェアアップデートの必要なファイル名７０２を抽出する。そして、更新案件管理部１１１は、対象のファイル名７０２から更新用ソフトウェアを抽出し、更新用ソフトウェアを車両２００に送信する（Ｓ１５１６）。

車両２００の更新データ要求部２１３は、テレマティクスセンタ１００から新しいソフトウェアを受信する（Ｓ１５０６）。更新データ要求部２１３は、受信したデータを記憶装置２１５に蓄積した上で、新しいソフトウェアを用いて対象ＥＣＵのソフトウェア更新処理を実行するする（Ｓ１５０７）。なお、ステップＳ１５０７で行われる処理は、図７に示す第１の実施形態の処理と同様である。そして、更新データ要求部２１３は、アップデートが完了した後、その実行結果をテレマティクスセンタ１００に送信する（Ｓ１５０８）。ここで、実行結果は、更新日時、実消費電力、ロールバック実行回数、アップデートを実行した際の車両２００の位置情報、ソフトウェアダウンロード時の伝送速度などを示す情報である。

テレマティクスセンタ１００の更新案件管理部１１１は、車両２００からアップデートの実行結果を受信すると、発信元の車両２００のＶＩＮから更新案件ＤＢ１２１のＶＩＮ７２１を検索する。更新案件管理部１１１は、該当レコードの更新日時７２３〜更新実行位置７２８の情報を更新する。また、更新案件管理部１１１は、該当レコードの更新案件ＩＤ７２０と同一のＩＤを持つ更新案件ＩＤ７１０に対して、完了台数７１６に１を加えて更新する。さらに、更新案件管理部１１１は、図４に示す第１の実施形態のステップＳ８０２〜ステップＳ８０３と同様の方法で、ユーザが所有する携帯端末３００に対して、実行結果情報と共にアップデート完了を通知する（Ｓ１５１７）。

携帯端末３００の更新情報表示部３１１は、テレマティクスセンタ１００から実行結果情報を受信すると、実行結果情報を入出力装置３３０に表示させる（Ｓ１５２０）。なお、更新案件がない、あるいは残電力量が閾値を上回っていない場合（Ｓ１５０４：Ｎｏ）には、更新を実行しなかったという結果を携帯端末３００に送信するため、ステップＳ１５０８、ステップＳ１５１７、ステップＳ１５２０の処理を実行する。ＥＣＵのソフトウェア更新を実行しなかった場合には、ステップＳ１５２０の処理は実行しなくともよい。 また、図６に示す第１の実施形態のステップＳ１００３〜ステップＳ１００４の処理と同様に、ソフトウェアのダウンロードおよびインストールを実行する前に、ユーザから実行許諾を取得するようにしてもよい。

図１２は、第２の実施形態のソフトウェア更新システムにおいて、テレマティクスセンタ１００の更新条件変更部１１５により、図１１のステップＳ１５１３で実行される処理の一例を示す図である。

図１２において、テレマティクスセンタ１００の更新条件変更部１１５は、図１１のステップＳ１５０１でアップデート有無を問い合わせた車両２００のＶＩＮを用いて、更新案件ＩＤ７２０を１件抽出する（Ｓ１６００）。更新条件変更部１１５は、抽出した更新案件ＩＤ７２０を用いて、同一のＩＤを持つ更新案件ＩＤ７２０のレコードを全て検索し、既に更新が完了した車両についての実績消費電力７２４、ファイル伝送速度７２５、更新実行位置７２８を収集する（Ｓ１６０１）。更新条件変更部１１５は、図１１のステップＳ１５０１で送信された車両２００の現在位置を用いて、現在位置から距離Ｄｋｍ以内となる更新実行位置７２８が存在するレコードを抽出する（Ｓ１６０２）。

更新条件変更部１１５は、さらに、図１１のステップＳ１５０１で送信された通信速度Ｃｂｐｓ（ｂｉｔ ｐｅｒ ｓｅｃｏｎｄ）を用いて、ファイル伝送速度７２５がＣのＴＵ％以下、かつＣのＴＤ％以上であるレコードを抽出する（Ｓ１６０３）。例えば、ＴＵが１０５、ＴＤが９５であった場合、対象となるレコードは、通信速度がＣの９５％〜１０５％の範囲内に収まる環境下でソフトウェア更新が実行されたものとなる。なお、伝送速度を用いた閾値の決定方法はこれに限られるものではなく、例えば「ＣのＴＵ％以下」や「ＣのＴＤ％以上」という条件のどちらか一方のみを用いてもよい。

更新条件変更部１１５は、ステップＳ１６０３で抽出したレコードに含まれる実績消費電力７２４の情報から、更新処理に必要な電力量の分布を作成する（Ｓ１６０４）。次に、更新条件変更部１１５は、作成した電力量の分布から、「ソフトウェア更新に必要であった電力量（消費電力量）がその値以下である」車両の割合が、各グループの更新済みの車両に対してＡ％以上となるような電力量の値Ｔ３を算出する（Ｓ１６０５）。そして、更新条件変更部１１５は、算出したＴ３を、ソフトウェア更新時に必要となる可能性の高い電力量の期待値、すなわち実行判断の閾値として決定する（Ｓ１６０６）。決定された閾値は、図１１に示すステップＳ１５１４にて、テレマティクスセンタ１００から車両２００に送信されることになる。

ステップＳ１６０６で決定する実行判断閾値の値は、必ずしもステップＳ１６０５で算出した値でなくてもよく、該当する更新案件の全車両のアップデート実績の中で最も値の大きい実績消費電力７２４を利用してもよい。また、該当する更新案件のアップデートが完了した他の車両２００の実績消費電力７２４を利用するのではなく、これからアップデートを実行する車両２００が過去に別の更新案件でアップデートした時の実績消費電力７２４を利用することで、実行判断閾値７１４を算出してもよい。なお、ステップＳ１６０２による位置情報を用いたレコードの抽出処理、およびステップＳ１６０３による通信速度を用いたレコードの抽出処理は、どちらか一方のみを実行するようにしてもよい。

上述した実施形態によれば、第１の実施形態で説明した（１）、（３）と同様の作用効果に加えて、次の作用効果が得られる。
（４）テレマティクスセンタ１００の中央演算処理装置１１０は、車両２００の中央演算処理装置２１１により取得されるテレマティクスセンタ１００と車両２００との間の通信速度に関する情報と、電力量に関する情報とに基づいて、電力量の閾値を変更する。このようにしたので、通信速度も加味して更新に要する電力量の閾値を変更することができる。
（５）テレマティクスセンタ１００の中央演算処理装置１１０は、車両２００の中央演算処理装置２１１により取得される車両２００の位置に関する情報と、電力量に関する情報とに基づいて、電力量の閾値を変更する。このようにしたので、位置情報も加味して更新に要する電力量の閾値を変更することができる。
たとえばビルの陰に駐車している車両２００は、受信する電波の電界強度が低く、更新プログラムを受信しづらい環境である。受信電波の電界強度が低い場所での更新プログラムの受信は時間を要するので、基準とする電界強度よりも低い電界強度ではプログラム更新に要する電力量閾値を大きくする補正を行う。

（第３の実施形態）
図１３に、本発明の第３の実施形態に係るソフトウェア更新システムによる処理の一例を示す。第３の実施形態に係るソフトウェア更新システムは、図１に示す第１の実施形態に係るソフトウェア更新システムと同様の構成を有している。また、特に説明しない点については、第１の実施形態と同様である。第３の実施形態では、更新条件変更部１１５による実行判断閾値７１４を変更する処理が、第１の実施形態と異なる。

図１３において、テレマティクスセンタ１００の更新条件変更部１１５は、対象台数７１５が完了台数７１６と一致しない、すなわち全車両の更新が完了していない案件の更新案件ＩＤ７１０を１件抽出する（Ｓ１７００）。更新条件変更部１１５は、抽出した更新案件ＩＤ７１０を用いて、同一のＩＤを持つ更新案件ＩＤ７００のレコードを検索し、アップデート対象としているＥＣＵのＥＣＵＩＤ７０１を１つ以上抽出する（Ｓ１７０１）。そして、更新条件変更部１１５は、ＥＣＵ毎に必要な消費電力量を推定するべく、消費電力ログ情報７２７に抽出したＥＣＵＩＤ７０１が含まれるレコードを検索し、ＥＣＵＩＤと実績消費電力量のペア情報を抽出する（Ｓ１７０２）。このとき、ステップＳ１７００で抽出した更新案件ＩＤ７１０と、該当レコードの更新案件ＩＤ７２０が一致するかは問わない。

更新条件変更部１１５は、ＥＣＵＩＤ毎に抽出した実績消費電力量の情報から、ＥＣＵＩＤ毎に更新処理に必要な電力量の分布を作成する（Ｓ１７０３）。そして、更新条件変更部１１５は、各ＥＣＵＩＤの消費電力量の分布から、「該当するＥＣＵＩＤを持つＥＣＵのソフトウェア更新に必要であった電力量（消費電力量）がその値以下である」車両の割合が、各グループの更新済みの車両に対してＡ％以上となるような電力量の値Ｅ１、Ｅ２、・・・をそれぞれ算出する（Ｓ１７０４）。電力量の値は、ステップＳ１７００で抽出した更新案件ＩＤ７１０が更新対象とするＥＣＵの数だけ算出される。なお、ＥＣＵの種別に応じて、基準となるＡ％の値を個別に変更してもよい。

更新条件変更部１１５は、算出したＥ１、Ｅ２、・・・の合計値ＥＴを更新実行判断の閾値として算出し、更新案件に紐付く更新案件ＩＤ７１０のレコードにある実行判断閾値７１４を変更する（Ｓ１７０５）。そして、更新条件変更部１１５は、対象台数７１５が完了台数７１６と一致しない、すなわちまだ全車両の更新が完了していない案件の更新案件ＩＤ７１０全てについて、実行判断閾値７１４の変更が完了したか否かを確認する（Ｓ１７０６）。更新条件変更部１１５は、全ての更新案件に対して閾値の変更が完了した場合（Ｓ１７０６：Ｙｅｓ）は、図１３に示す処理を終了する。更新条件変更部１１５は、閾値の変更が完了していない他の更新案件が存在する場合（Ｓ１７０６：Ｎｏ）は、全ての更新案件の閾値の変更が完了するまで、ステップＳ１７００〜ステップＳ１７０５の処理を繰り返し実行する。

上述した実施形態によれば、第１の実施形態で説明した（１）、（３）と同様の作用効果に加えて、次の作用効果が得られる。
（６）車両２００は複数のＥＣＵ２２０，２３０，２４０，２５０を搭載している。車両２００が有する複数のＥＣＵ２２０，２３０，２４０，２５０の各々のソフトウェアの更新に要した電力量は個別に演算され、これらの電力量閾値は、たとえば携帯端末３００に表示される。携帯端末３００には車両２００の残電力量も表示される。したがって、ユーザは更新対象であるＥＣＵ２２０，２３０，２４０，２５０ごとの電力量閾値と残電力量とを参照して、ＥＣＵごとにソフトウェアを変更させることができる。

次のような変形も本発明の範囲内であり、変形例の一つ、もしくは複数を上述の実施形
態と組み合わせることも可能である。

（変形例１）
上述した実施形態および変形例では、実行判断可否に用いる消費電力量の閾値を、過去の実績を用いて算出する例を説明したが、過去の実績を用いて、更新に必要とされる更新時間の閾値を算出するようにしてもよい。また、例えば、ステップＳ１００３〜ステップＳ１００４のユーザ許諾取得の際の判断基準として、算出した更新時間の閾値をユーザに提示するようにしてもよい。算出した更新時間の閾値をテレマティクスセンタ１００の入出力装置１３０に表示するようにしてもよい。なお、算出した消費電力量の閾値と併せて、更新時間の閾値をユーザに提示するようにしてもよい。ユーザは、携帯端末３００に表示される更新時間の閾値を確認して、ソフトウェアの更新に関する処理の実行可否を判断することができる。

上記では、種々の実施の形態および変形例を説明したが、本発明はこれらの内容に限定されるものではない。本発明の技術的思想の範囲内で考えられるその他の態様も本発明の範囲内に含まれる。

１００：テレマティクスセンタ
２００：車両
３００：携帯端末
４００，５００：ネットワーク

Claims (14)

1. 車両に搭載される制御装置と、前記制御装置とネットワークを介して通信を行うサーバとを備え、前記制御装置のソフトウェアの更新を管理するソフトウェア更新システムであって、
   前記サーバは、少なくとも、前記制御装置が前記ソフトウェアを更新する際に要した電力量に関する情報に基づいて、前記ソフトウェアの更新の実行可否を判断する電力量閾値を演算して出力する閾値演算制御部を備え、
   前記制御装置は、前記サーバが電力量閾値を出力した後に受信したソフトウェア更新指令にしたがってソフトウェア更新処理を実行するソフトウェア更新システム。
2. 請求項１に記載のソフトウェア更新システムにおいて、
   前記閾値演算制御部は、前記ソフトウェアの更新の際に実行したロールバック回数に関する情報と、前記電力量に関する情報とに基づいて、前記電力量閾値を演算するソフトウェア更新システム。
3. 請求項１に記載のソフトウェア更新システムにおいて、
   前記閾値演算制御部は、前記サーバと前記制御装置との間の通信速度に関する情報と、前記電力量に関する情報とに基づいて、前記電力量閾値を演算するソフトウェア更新システム。
4. 請求項１または請求項３に記載のソフトウェア更新システムにおいて、
   前記閾値演算制御部は、前記制御装置により取得される前記車両の位置に関する情報と、前記電力量に関する情報とに基づいて、前記電力量閾値を演算するソフトウェア更新システム。
5. 請求項１に記載のソフトウェア更新システムにおいて、
   前記車両が前記制御装置を複数備えている場合、
   前記電力量に関する情報は、複数の前記制御装置の各々のソフトウェアの更新に要した電力量に関する情報であるソフトウェア更新システム。
6. 請求項１から請求項５のいずれか一項に記載のソフトウェア更新システムにおいて、
   前記閾値演算制御部から出力された電力量閾値を受信して表示部に表示する携帯端末をさらに含むソフトウェア更新システム。
7. 請求項６に記載のソフトウェア更新システムにおいて、
   前記サーバは、前記制御装置により取得される前記ソフトウェアの更新に要した時間に関する情報に基づいて、前記ソフトウェアの更新の実行可否を判断するための更新所要時間の閾値を演算し、
   前記携帯端末は、前記更新所要時間の閾値に関する情報を前記表示部に表示させるソフトウェア更新システム。
8. 車両が有する制御装置のソフトウェアの更新を管理するサーバであって、
   前記制御装置から送信される前記ソフトウェアを更新する際に要した電力量に関する情報に基づいて、前記ソフトウェアの更新の実行可否を判断する電力量閾値を演算する閾値演算制御部と、
   前記制御装置から送信される前記電力量に関する情報を受信し、前記閾値演算制御部で演算された前記電力量閾値を前記制御装置に送信する通信部とを備えるサーバ。
9. 請求項８に記載のサーバにおいて、
   前記通信部は、前記制御装置から前記ソフトウェアの更新の際に実行したロールバック回数に関する情報を受信し、
   前記閾値演算制御部は、前記ロールバック回数に関する情報と、前記電力量に関する情報とに基づいて、前記電力量閾値を演算するサーバ。
10. 請求項８に記載のサーバにおいて、
    前記閾値演算制御部は、前記サーバと前記制御装置との間の通信速度に関する情報と、前記電力量に関する情報とに基づいて、前記電力量閾値を演算するサーバ。
11. 請求項８または請求項１０に記載のサーバにおいて、
    前記通信部は、前記制御装置から前記車両の位置に関する情報を受信し、
    前記閾値演算制御部は、前記位置に関する情報と、前記電力量に関する情報とに基づいて、前記電力量閾値を演算するサーバ。
12. 請求項８に記載のサーバにおいて、
    前記電力量に関する情報は、前記車両が有する複数の前記制御装置の各々のソフトウェアの更新に要した電力量に関する情報であるサーバ。
13. 請求項８から請求項１２のいずれか一項に記載のサーバにおいて、
    前記電力量閾値に関する情報を表示する表示部をさらに備えるサーバ。
14. 請求項１３に記載のサーバにおいて、
    前記通信部は、前記制御装置から前記ソフトウェアの更新に要した時間に関する情報を受信し、
    前記閾値演算制御部は、前記時間に関する情報に基づいて、前記ソフトウェアの更新に関する処理の実行可否を判断するための更新所要時間の閾値を演算し、
    前記表示部は、前記更新所要時間の閾値に関する情報を表示するサーバ。

Images