JP5975964B2 - 情報処理プログラム、情報処理方法、情報処理装置、及び情報処理システム - Google Patents

Description

本発明は、ネットワークを介したソフトウェアの更新方法に関する。

情報処理装置のソフトウェアの更新方法の一例として、情報処理装置が、ネットワークを介して接続された更新サーバから更新ファイルを取得して、取得したソフトウェアを適用する方法がある。ネットワークを介してソフトウェアを更新する方法の一例として、例えば以下の第１、第２、及び第３の技術がある。

第１の技術では、サーバは、組込み機器の情報の書き換えを予め定められた管理者が許可するか否かを示す承認情報を有する。組込み機器は、情報への書き換え要求を受けた場合、承認確認要求を送出する。サーバは、承認確認要求への結果を応答し、組込み機器は、許可を示す承認確認応答を受け取った場合にのみ、情報の書き換えを許可する。

第２の技術では、通信ネットワークを介してユーザに対して遠隔サービスを認証する方法が開示されている。遠隔サービスは第１の秘密鍵に基づき符号生成アルゴリズムを使用して生成したサービス認証符号を獲得する。サービス認証符号を、通信ネットワークを介してユーザに伝達し、ユーザに付随する認証デバイスに受信するか、または入力する。認証デバイスは、次いで第２の秘密鍵に基づき同じ符号生成アルゴリズムを使用して予期符号値を生成し、予期符号値をサービス認証符号と比較する。比較に応じ、予期符号値がサービス認証符号と相関する場合に、認証デバイスは遠隔サービスの真正性をユーザに示す応答を生成する。

第３の技術では、ホスト（配信用コンピュータ）がサービス提供処理を実行する新モジュールを配信する。そして、端末が制御プログラムの旧モジュールをホストにより配信された新モジュールに更新し、更新した新モジュールの動作検証処理を実行し、動作検証処理でエラーを検出した時にエラー対処処理を実行する。

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

更新対象のソフトウェアが自動車で稼動する場合、自動車の挙動に影響を及ぼさないようにするため、ソフトウェアの更新は自動車が停止した状態で行われることが考えられる。このためソフトウェアの更新で使用される電力は、自動車に搭載されたバッテリから供給される。しかしながら、自動車に搭載されるバッテリの容量には限りがある。ソフトウェアの更新量が大きい場合には、更新で使用される電力量も大きくなり、その結果バッテリを大量に消費してしまう。自動車に搭載されるバッテリは、自動車の起動時にも使用されるものであるので、ソフトウェアの更新でバッテリを大量に消費すると、自動車の起動ができなくなる等の問題が発生する場合がある。

そこで、１つの側面では、本発明は、自動車で稼動するソフトウェアの更新処理において、バッテリの枯渇を防ぐための方法を提供することを目的とする。

一態様によるプログラムがコンピュータに実行させる処理は、自動車に搭載された機器を制御する制御プログラムが動作する自動車から、制御プログラムについての更新要求を受信し、記憶部に記憶された、自動車が属する車種に対応するバッテリの使用可能電力量に基づいて、更新要求に対応する複数の修正プログラムを複数のグループに分類し、グループ毎に分類された修正プログラムを自動車に送信することを含む。

また、一態様によるプログラムがコンピュータに実行させる処理は、インストール対象の自動車に対する１以上の修正プログラムを受信し、記憶部に記憶された、自動車が停止した時間帯を示す履歴情報に基づいて、自動車が定期的に停止した時間帯を特定し、特定した時間帯に自動車が停止している場合、自動車のバッテリ残量に応じて、受信した１以上の修正プログラムをインストールすることを含む。

１実施態様によれば、自動車で稼動するソフトウェアの更新処理において、バッテリの枯渇を防ぐための方法を提供することができる。

情報処理装置の一実施例の構成を図解した機能ブロック図である。 本実施形態に係る、自動車に搭載されたＥＣＵの更新システムの一例を示す。 本実施形態に係る更新サーバの構成の一例を示す。 同意情報の構成の一例を示す。 本実施形態に係る容量管理情報の構成の一例を示す。 消費電力情報の一例を示す。 セキュリティ確保部が公開鍵とハッシュ関数を管理するための鍵管理情報の一例を示す。 更新サーバにおける更新ファイルの送信処理の動作フローを図解したフローチャートである。 車載器の構成の一例を示す。 車両履歴情報の構成の一例を示す。 車載器におけるインストール処理の動作フローを図解したフローチャートである。 本実施形態に係るＥＣＵの構成の一例を示す 更新サーバのハードウェア構成の一例を示す。 車載器のハードウェア構成の一例を示す。

図１は、情報処理装置の一実施例の構成を図解した機能ブロック図である。
情報処理装置７は、記憶部１、受信部２、分類部３、送信部４、確認部５、及び算出部６を含む。

記憶部１は、自動車が属する車種に対応づけて、自動車のバッテリの使用可能電力量を記憶する。

受信部２は、自動車に搭載された機器を制御する制御プログラムが動作する自動車から、制御プログラムについての更新要求を受信する。

分類部３は、制御プログラムが動作する自動車に対応する使用可能電力量に基づいて更新要求に対応する複数の修正プログラムを複数のグループに分類する。また、分類部３は、制御プログラムを実行する制御部であって、自動車に搭載される該制御部における、制御プログラムに対する修正プログラムをインストールするために使用される予測の消費電力量の合計値が、使用可能電力量よりも大きい場合、複数の修正プログラムを複数のグループに分類する。また、分類部３は、消費電力量の合計値と使用可能電力量とに基づいて決定した数のグループに、複数の修正プログラムを分類する。

送信部４は、グループ毎に分類された修正プログラムを自動車に送信する。
確認部５は、複数の修正プログラムが分類された複数のグループのうちの第１のグループに分類された修正プログラムが正常に受信されたか否かを示す確認情報を受信する。すると送信部４は、確認情報により、第１のグループに分類された修正プログラムが正常に受信されたことを確認した後に、複数のグループのうちの第２のグループに分類された修正プログラムの送信を開始する。

算出部６は、制御部毎に対応付けて記憶部１に記憶された、単位サイズの修正プログラムをインストールするために使用される消費電力量に基づいて、消費電力量の合計値を算出する。

情報処理装置１０は、受信部８と処理部９を含む。
受信部８は、インストール対象の自動車が属する車種に対応するバッテリの使用可能電力量に基づいて複数のグループに分類された修正プログラムを、グループ毎に受信する。

処理部９は、インストール対象の自動車のバッテリ残量に応じて、グループ毎に、分類された修正プログラムをインストールする。また、処理部９は、インストール対象の自動車が所定の時間以上停止することが見込まれるタイミングで、複数のグループのうちのいずれかのグループに分類された修正プログラムをインストールする。また、処理部９は、インストール対象の自動車のバッテリ残量が所定の閾値以上である場合に、複数のグループのうちのいずれかのグループに分類された修正プログラムをインストールする。

図２は、本実施形態に係る、自動車に搭載されたＥＣＵ（Electric Control Unit）の更新システムの一例を示す。

図２において、更新システム２０は自動車２１と更新サーバ２２を含む。そして自動車２１は車載器２３とＥＣＵ２４Ａ、２４Ｂ、２４Ｃを含む。更新サーバ２２と車載器２３はネットワークを介して接続される。そして、車載器２３とＥＣＵ２４はネットワークまたはバスを介して接続される。更新サーバ２２と車載器２３を接続するネットワークには、例えば無線ネットワークがある。ＥＣＵ２４と車載器２３を接続するネットワークには、例えばＣＡＮ（Controller Area Network）やＦｌｅｘＲａｙなどがある。以下の説明では、ＥＣＵ２４Ａ、２４Ｂ、２４Ｃを特に区別しない場合には、単にＥＣＵ２４と記す。

更新サーバ２２は、自動車２１に対して、ＥＣＵ２４で稼動するソフトウェアの更新ファイルを配布する情報処理装置である。更新サーバ２２は、自動車２１の車載器２３に対して更新ファイルを送信し、その後車載器２３から更新ファイル適用後の各ＥＣＵ２４の構成情報を受信する。そして更新サーバ２２は、受信した構成情報に基いて、ファイルの更新が成功したか否かを判定する。

車載器２３は、ネットワークを介して更新サーバ２２と情報の通信が可能な装置である。車載器２３は、更新サーバ２２から更新ファイルを受信し、受信した更新ファイルを更新対象のＥＣＵ２４にインストール（適用）するように指示する。また、車載器２３は、各ＥＣＵ２４で稼動するソフトウェアの状態を示す構成情報を収集して、更新サーバ２２に送信する。車載器２３は、更新サーバ２２と各ＥＣＵ２４に対して通信可能であれば特に限定されず、カーナビゲーション装置や、自動車２１に設置可能なスマートフォンなどでもよい。

ＥＣＵ２４は、エンジンの制御で用いられる各種のセンサを含むセンサ系統、エンジンの動作、及び自動車に搭載される各種機器を制御する。ＥＣＵ２４は車載器２３から更新ファイルのインストール指示を受信し、更新ファイルのインストール処理を行う。また、ＥＣＵ２４は更新ファイルのインストール処理が完了すると、自身の構成情報を取得して車載器２３に通知する。ソフトウェアの更新は、更新ファイルのインストール処理と、更新ファイルの有効化処理の２段階で行われ、更新ファイルの有効化は、更新サーバ２２からの更新の有効化の指示を受け取った後に行われる。尚、ソフトウェアの構成情報は例えば、ソフトウェアの各種パラメータであって、当該パラメータが正常であればソフトウェアが正常であることが保証されるパラメータである。

尚、更新ファイルは不具合のあるソフトウェアに適用される形式のソフトウェアでもよいし、不具合の見つかったソフトウェアと入れ替わる形式のソフトウェアでもよい。具体的には例えば更新ファイルはソフトウェアのパッチである。尚、自動車に不具合が発見された場合、その不具合を解消するには複数の更新ファイルのインストールが必要になることがある。本実施形態の以下の説明では、自動車に搭載されたＥＣＵで稼動するソフトウェアに不具合が発見された場合を考え、その不具合を解消するための１以上の更新ファイルを、適用対象の更新ファイルと記す。

また、以下の説明では、自動車２１が更新ファイルを更新サーバ２２から受信して、受信した更新ファイルの適用を行うことをリモートメンテナンスと記す。また、インストール処理対照の車両を対象車両と記す。

次に、更新サーバ２２の構成について説明する。図３は、本実施形態に係る更新サーバ２２の構成の一例を示す。

更新サーバ２２は、認証部３１、電力算出部３２、分割部３３、送信部３４、セキュリティ確保部３５、及び検証部３６を含む。

更新サーバ２２は情報処理装置７の一例である。認証部３１は受信部２の一例である。電力算出部３２は算出部６の一例である。分割部３３は分類部３の一例である。送信部３４は送信部４及び確認部５の一例である。

認証部３１は、更新ファイルの送信処理及びインストール処理の開始前に、対象車両のリモートメンテナンスに対する所有者からの同意を得たか否かを確認する。対象車両のリモートメンテナンスに対する所有者からの同意を得たか否かの確認には、事前登録された情報を用いた同意確認と、更新作業開始時に所有者から直接同意を得ることによる同意確認が含まれる。尚、対象車両のリモートメンテナンスに対する所有者からの同意を得たか否かの確認は、事前登録された情報を用いた確認または更新作業開始時に所有者から直接同意を得ることによる確認のうち、どちらか一方としてもよい。尚、事前登録された情報を用いた同意確認は、車載器２３から確認要求を受信した場合に認証部３１により実行されてもよい。

対象車両のリモートメンテナンスに対する所有者からの同意を得たか否かの確認のために、認証部３１は予め同意確認のための情報を収集し、所定の記憶領域に記録しておく。このような同意確認のための情報を同意情報と記す。

図４は、同意情報の構成の一例を示す。図４において、同意情報４０は、車両ＩＤ４１、同意フラグ４２、所有者ＩＤ４３、認証方法４４、及び認証情報４５を含む。

車両ＩＤ４１は、自動車２１を一意に識別するための識別情報である。同意フラグ４２は、車両ＩＤ４１で示される車両が、その車両の所有者からリモートメンテナンスの事前同意を得ているか否かを示す情報である。所有者ＩＤ４３は、車両ＩＤ４１で示される車両を所有する所有者を一意に識別するための識別情報である。尚、所有者ＩＤ４３については、一つの車両に対して複数人を登録することが可能である。認証方法４４は、更新作業開始時に認証部３１が車両の所有者を認証する方法を示す情報である。認証方法４４は、例えば、所有者の指紋、音声、または画像を用いた認証等の種々の方法とすることができる。認証情報４５は、更新作業開始時の認証方法４４による認証において使用される情報である。

事前登録された情報を用いた同意確認について、認証部３１は、同意情報４０を参照して、リモートメンテナンスを行う対象の車両が、事前にその車両の所有者からリモートメンテナンスの同意を得ているか否かを判定する。すなわち認証部３１は、同意情報４０から、対象車両の識別情報と一致する車両ＩＤ４１のレコードを抽出する。次に認証部３１は、抽出したレコードの同意フラグ４２を確認し、同意フラグ４２の値が、リモートメンテナンスの事前同意を得ていることを示す値（例えば「Ｔｒｕｅ」）であれば車両の所有者からリモートメンテナンスの同意を得ていると判定する。一方認証部３１は、同意フラグ４２の値が、車両の所有者からリモートメンテナンスの事前同意を得ていないことを示す値（例えば「Ｆａｌｓｅ」）であれば車両の所有者からリモートメンテナンスの同意を得ていないと判定する。

対象車両のリモートメンテナンスに対する所有者の事前同意を得ていると判定した場合、認証部３１は、更新作業開始時に所有者から直接同意を得ることによる同意確認を行う。

すなわち認証部３１は、改めて、リモートメンテナンスに所有者が同意する旨の情報である同意確認情報を対象車両から取得する。同意確認情報には、リモートメンテナンスに同意したのが真の所有者であることを確認するための認証情報が含まれる。認証情報には例えば、所有者の指紋、音声、画像（顔写真）の情報が含まれる。認証部３１は同意情報４０から対象車両の識別情報と一致するレコードを抽出し、対象車両から受信した認証情報と、抽出したレコードの認証情報４５の値とを比較する。そして認証部３１は、対象車両から受信した認証情報と抽出したレコードの認証情報４５の値とが一致する場合、対象車両の真正の所有者からリモートメンテナンスの同意を得たと判定する。また認証部３１は対象車両から受信した認証情報と抽出したレコードの認証情報４５の値とが一致しない場合、対象車両の真正の所有者からはリモートメンテナンスの同意を得ていないと判定する。対象車両の真正の所有者からリモートメンテナンスの同意を得たと判定した場合、認証部３１は、車載器２３から受信した同意確認情報をエビデンスとして所定の記憶領域に保存する。

図４において、車両ＩＤ４１が「Ａ」、同意フラグ４２が「Ｔｒｕｅ」、所有者ＩＤ４３が「３９４８Ａ８Ｃ３３」、認証方法４４が「指紋」、認証情報４５が「指紋データ１」のレコードが格納されている。これは、車両ＩＤ４１が「Ａ」の車両が、所有者からリモートメンテナンスの事前同意を得ており、車両ＩＤ４１が「Ａ」の所有者は、所有者ＩＤ４３「３９４８Ａ８Ｃ３３」で示される所有者であることが示される。さらに、車両ＩＤ４１が「Ａ」の車両のリモートメンテナンス開始時には、「指紋認証」による所有者の認証が行われ、所有者から入力された指紋情報と、「指紋データ１」の情報が照合されて、照合が一致した場合に、認証が成功したと判定されることが示される。

また、図４において、車両ＩＤ４１が「Ｄ」、同意フラグ４２が「Ｆａｌｓｅ」、所有者ＩＤ４３、認証方法４４、認証情報４５が「−」のレコードが格納されている。これは、車両ＩＤ４１が「Ｄ」の車両は、所有者からリモートメンテナンスの事前同意を得ていないことが示されている。従って、車両ＩＤ４１が「Ｄ」の車両については、リモートメンテナンス処理は行われない。

尚、対象車両のリモートメンテナンスに対する所有者からの同意を得たことの確認後に、対象車両に対して更新ファイルの送信が行われることとなる。よって、所有者がリモートメンテナンスに同意する旨が含まれる同意確認情報は、言い換えると、所有者からの更新ファイルの配信要求と捉えることもできる。

電力算出部３２は、対象車両における、適用対象の全ての更新ファイルのインストール処理にかかる消費電力を算出する。そして算出した消費電力を、電力算出部３２は、更新ファイルをインストールするために使用可能な対象車両のバッテリの電力量と比較する。これにより電力算出部３２は、すべての更新ファイルの更新処理を一度に実施できるか否かを判定する。

具体的には電力算出部３２は、予め車種毎に、バッテリの容量のうち、更新ファイルのインストールに使用可能な最大電力量である使用可能電力量を所定の記憶領域に記憶しておく。

例えば車両に搭載されたバッテリは、エンジンの始動において用いられるため、バッテリの容量をすべて更新ファイルの更新処理で使用できるわけではない。そこで、バッテリの容量のうち更新ファイルのインストール処理に使用することのできる電力量をポリシとして電力算出部３２は記憶しておく。ここで、電力算出部３２がバッテリの容量のうち更新ファイルのインストール処理に使用することのできる電力量を車種毎に管理するための情報を、以下の説明では容量管理情報と記す。図５は、本実施形態に係る容量管理情報の構成の一例を示す。

容量管理情報５０は、車種ＩＤ５１、最大容量５２、基本電力量５３、及び使用可能電力量５４のデータ項目を含む。車種ＩＤ５１は、車種を一意に識別するための識別情報である。最大容量５２は、車種ＩＤ５１で示される車種に搭載されるバッテリの最大容量を示す情報である。基本電力量５３は、車種ＩＤ５１で示される車種に搭載されるバッテリの容量のうちエンジンの始動等に用いられる最低限確保しておかなくてはならないバッテリの残量を示す情報である。使用可能電力量５４は、車種ＩＤ５１で示される車種に搭載されるバッテリの容量のうち更新ファイルのインストールに使用することのできる最大電力量を示す情報である。ここで、使用可能電力量５４は例えば、バッテリの最大容量５２から基本電力量５３を減算した値の１／ｎ（ｎは正の整数）の値とすることができる。

尚、以下の説明では、エンジンの始動等に用いられる最低限確保しておかなくてはならないバッテリの残量を基本電力量と記す。

電力算出部３２は、また、予め各ＥＣＵ２４に対応付けて、単位サイズ毎の更新ファイルのインストール処理にかかる消費電力の値を所定の記憶領域に記憶しておく。ここで、ＥＣＵ２４毎に対応付けられた、単位サイズ毎の更新ファイルの更新処理にかかる消費電力の値を管理するための情報を、以下の説明では消費電力情報と記す。消費電力情報は、対象車両の更新ファイルの更新にかかる消費電力の算出のために使用される。このようにＥＣＵ２４毎に対応付けて消費電力を管理するのは、各ＥＣＵ２４は処理能力に個体差があり、単位サイズあたりの更新ファイルを更新するためにかかる消費電力も異なるからである。

図６は、消費電力情報の一例を示す。消費電力情報６０は、ＥＣＵＩＤ６１と、処理バイト単位の消費電力６２とを含む。ＥＣＵＩＤ６１は、ＥＣＵ２４を一意に識別するための識別情報である。処理バイト単位の消費電力６２は、ＥＣＵＩＤ６１で示されるＥＣＵ２４において、例えば１Ｋｂｙｔｅの更新ファイルのインストール処理で消費される電力量を示す情報である。

対象車両の全ての更新ファイルのインストール処理にかかる消費電力の算出において、電力算出部３２は先ず、消費電力情報６０と更新ファイルのサイズとに基づいて、各更新ファイルのインストール処理にかかる消費電力を算出する。具体的には電力算出部３２は、消費電力情報６０において、各更新ファイルが稼動するＥＣＵ２４のＥＣＵＩＤ６１のレコードを抽出し、抽出したレコードの、処理バイト単位の消費電力６２の値を取得する。そして電力算出部３２は取得した処理バイト単位の消費電力６２の値を、更新ファイルのサイズに掛けて、各更新ファイルのインストール処理で消費される電力量を算出する。このように各ＥＣＵ２４に含まれるすべての更新ファイルについて、インストール処理にかかる消費電力を電力算出部３２は算出する。そして電力算出部３２は、算出した、各ＥＣＵ２４に含まれるすべての更新ファイルの消費電力量を合計して、対象車両の全ての更新ファイルのインストール処理にかかる消費電力量を算出する。以下の説明では、全ての更新対象ファイルのインストール処理にかかる消費電力量の合計値を更新総消費電力と記す。

以上のようにして電力算出部３２は、更新総消費電力を算出し、また、容量管理情報５０を参照して対象車両の車種に対応する使用可能電力量を取得し、算出した更新総消費電力と取得した使用可能電力量を比較する。

分割部３３は、電力算出部３２により更新総消費電力が使用可能電力量より大きいと判定された場合、適用対象の複数の更新ファイルを複数のグループに分割（分類）する。

具体的には分割部３３は、更新総消費電力を、対象車両のバッテリの使用可能電力量で割った値（小数点以下切り上げ）の数のグループに、更新ファイルを分割（分類）する。このように分割（分類）されたグループ毎に、対象車両では、更新ファイルが適用されるように制御される。そして一つのグループのインストール処理の完了後に、バッテリの充電が行われ、次のグループのインストール処理が行われるように制御する。これにより、インストール処理においてバッテリが枯渇することを防ぐことができる。

また分割部３３は、依存関係のある更新ファイル同士は同一グループ内に含まれるように、更新ファイルを分割（分類）する。依存関係のあるファイル同士とは、更新ファイル群のうち、一方のファイルを更新した場合に、同時に他方も更新する必要のあるファイル同士を指す。このような依存関係のある更新ファイル群には、例えば、あるソフトウェアとそのソフトウェアの出力値を入力とするソフトウェアがある。

依存関係のあるファイル同士を２つ以上のグループに跨らないようにすれば、グループ毎に順次更新処理を行い、更新処理の終了したグループから順次、更新の有効化を行うことができる。

しかしながら、更新ファイルの関係やバッテリの使用可能電力量によっては、依存関係のあるファイル同士が２つ以上のグループに跨る場合も考えられる。この場合には、依存関係のある複数のファイルが含まれる複数のグループは、同じタイミングで更新の有効化が行われるように制御される。このようにすることで、依存関係のある更新ファイルの一部のみが適用された状態で車両が始動することにより発生する不具合を防ぐことができる。

送信部３４は、更新ファイルを対象車両の車載器２３に送信する。送信部３４は、分割部３３により更新ファイルの分割（分類）が行われた場合には、分割（分類）されたグループ毎に更新ファイルを対象車両に送信する。更新ファイルをグループ毎に分割して送信するため、更新ファイルを受信した車載器は、更新ファイルのインストールをグループ毎に行うことが容易になる。よって車載器においてバッテリを枯渇させないための処理にかかる負荷を軽減することができる。

また送信部３４は、送信した更新ファイルが正しく車載器２３で受信されたことの確認を行う。送信した更新ファイルが正しく車載器２３で受信されたことの確認処理を、以下の説明では、送信処理ステータス確認と記す。

送信処理ステータス確認では、送信部３４は、送信した更新ファイルが正しく受信されたか否かを示す通知を車載器２３から受信し、この通知を確認することによって、送信した更新ファイルが正しく車載器２３で受信されたと判定する。

具体的には、車載器２３側での処理は後ほど説明するが、車載器２３は受信したファイルが正しく受信できたことを、デジタル署名等を用いて確認する。そして車載器２３はファイルが正しく受信できたか否かの情報、及び正しく受信できなかったファイルの識別情報を含むステータス情報を更新サーバ２２に通知する。ステータス情報を受信した送信部３４は、ステータス情報の内容を参照し、車載器２３でファイルが正しく受信できていない場合には、そのファイルの再送を行う。また、ステータス情報により、車載器２３で正しく受信されたことが確認できたファイルは、送信処理が完了したと送信部３４は判定する。

グループに含まれる全てのファイルの送信処理が完了したと判定した場合、送信部３４は、そのグループの送信処理が完了したことを示す送信完了通知を車載器２３に通知する。その後、次の未送信のグループに含まれる更新ファイルを車載器２３に送信する。

尚、更新ファイルの送信のタイミングとしては、対象車両のエンジンが起動中であることを確認してから送信部３４は更新ファイルを送信してもよい。すなわち、送信部３４は、更新ファイルの送信前に、車載器２３に対して対象車両のエンジンが起動しているか否かの問い合わせを送信する。そして送信部３４は、車載器２３から問い合わせに対する応答として、エンジンが起動しているか否かの情報を受信し、エンジンが起動している場合に、更新ファイルを送信してもよい。エンジンが停止している場合は、さらに、送信部３４は車載器２３に対して、バッテリの残量を問い合わせてもよい。そして、バッテリの残量が所定の閾値以上である場合に、更新ファイルを送信するようにしてもよい。尚、所定の閾値は、例えば、ダウンロード処理で消費される電力量に基本電力量を加えた値などとすることができる。

エンジンが起動していれば、エンジンの回転により発電が行われるので、十分な電力が供給される。対象車両のエンジンが起動中であることを確認してから更新ファイルを送信することで、対象車両においてダウンロード処理で使用される電力として、エンジンの回転により発電された電力を使用することができる。また、エンジンが停止中の場合には、対象車両のバッテリ容量が所定の閾値以上の場合に更新ファイルを送信することで、ダウンロード処理による車両のバッテリの枯渇を防ぐことができる。

検証部３６は、更新ファイルが正しくインストール（適用）されたか否かの検証を行う。検証部３６は検証のために予め所定の記憶領域に、更新ファイルが正しくインストールされた場合の正しい構成情報を記録しておく。更新ファイルが正しくインストールされた場合の正しい構成情報を以下の説明ではホワイトリストと記す。ホワイトリストは、例えば、対象車両の環境を再現した検証機や実機などを用いた検証により得られた構成情報である。

検証部３６は、車載器２３から更新ファイルのインストール後の構成情報を取得して、取得した構成情報とホワイトリストとを比較し、更新ファイルのインストールの成否を判定する。ソフトウェアの更新が失敗したと判定した場合、検証部３６は車載器２３に対して更新ファイルのインストール処理のリトライを指示する。一方、ソフトウェアの更新が成功したと判定した場合、検証部３６は車載器２３に対して更新ファイルのインストールが成功した旨を通知する。

尚、ソフトウェアの更新が失敗したと判定した場合、検証部３６は車載器２３に対して更新ファイルのインストール処理のロールバックを指示してもよい。

また検証部３６は、適用対象のすべての更新ファイルのインストールが成功したことを確認した場合、車載器２３に対して適用対象の更新ファイルのインストールが成功した旨を通知する。

尚、グループ間に依存関係のあるファイル同士が含まれない場合には、依存関係のあるファイル同士が含まれないグループ単位でインストールが成功したことを確認し、車載器２３に適用対象の更新ファイルのインストールが成功した旨を通知することもできる。例えば依存関係のある複数の更新ファイルが複数のグループに跨らない場合には、各グループに含まれるすべての更新ファイルのインストールが成功したことを確認する毎に、車載器２３に適用対象の更新ファイルのインストールが成功した旨を通知することができる。この場合、適用対象の更新ファイルのインストールが成功した旨の通知を受け取った車載器２３により、所有者からの更新ファイルの有効化の同意確認が行われ、同意が確認されれば、更新ファイルの有効化が行われる。すなわち、更新ファイルの依存関係による影響がない場合には、適用対象のすべての更新ファイルのインストール処理が完了するのを待たずに、インストールの成功が確認されたグループの更新ファイルからグループの有効化を行うことができる。

セキュリティ確保部３５は、更新サーバ２２と車載器２３の間の通信のセキュリティを確保するための仕組みを提供する。

本実施形態では、更新サーバ２２と車載器２３との通信のセキュリティを確保するために、暗号化およびデジタル署名が用いられる。デジタル署名のための公開鍵と秘密鍵とのペアは、更新サーバと車載器との組み合わせ毎に生成され、車載器の鍵ペアは、各車両の出荷時点に生成される。暗号化の対象となるデータは、相手の公開鍵により暗号化され、自らの秘密鍵で復号化される。デジタル署名は、更新サーバおよび車載器のそれぞれが保持する自らの秘密鍵により署名されることで行われる。よって、公開鍵と秘密鍵のペアは複数存在し、第一のペア（更新サーバの鍵ペア）については、更新サーバ２２が更新サーバ２２の秘密鍵を、車載器２３が更新サーバ２２の公開鍵を保持し、第二のペア（車載器の鍵ペア）は車載器２３が車載器２３の秘密鍵を、更新サーバ２２が車載器２３の公開鍵を保持することとなる。

車載器２３の鍵ペアは、各車載器２３に含まれるＴＰＭ（Trusted Platform Module）により作成されたものが用いられてもよい。

更新サーバ２２のセキュリティ確保部３５は、更新サーバ２２の秘密鍵を保持する。また、更新サーバ２２は、車載器２３の公開鍵、及び、送信データとデジタル署名の比較で用いるハッシュ関数を、車載器毎に管理する。図７は、セキュリティ確保部３５が車載器２３の公開鍵とハッシュ関数を管理するための鍵管理情報７０の一例を示す。鍵管理情報７０は、車載器ＩＤ７１、公開鍵７２、及びハッシュ関数７３のデータ項目を含む。車載器ＩＤ７１は車載器２３を一意に識別するための識別情報である。公開鍵７２は、車載器ＩＤ７１で識別される車載器２３の公開鍵の情報である。公開鍵７２は車載器ＩＤ７１の車載器２３の秘密鍵と対応する。ハッシュ関数７３は、送信データとデジタル署名の比較のために用いられるハッシュ関数である。このハッシュ関数７３は、車載器ＩＤ７１の車載器２３にも同じハッシュ関数が記憶される。鍵管理情報７０には、各車両の出荷時点に登録される。

次に、セキュリティ確保部３５による車載器２３の認証及び車載器２３からのデータの機密性の確認方法の一例として、デジタル署名を用いた方法について説明する。尚、認証及び機密性の確認の方法は以下で説明するデジタル署名を用いたものに限定されず、種々の方法が用いられてもよい。ここでは、セキュリティ確保部３５と車載器２３の間で送受信されるデータは暗号化される一例を説明する。

認証に当たって先ず車載器２３は、送信対象データのハッシュ値を、車載器２３に記憶されたハッシュ関数を用いて算出する。次に車載器２３は、算出したハッシュ値を自身の秘密鍵を用いて暗号化し、デジタル署名を作成する。そして車載器２３は、作成したデジタル署名と送信対象データとを、更新サーバ２２の公開鍵を用いて暗号化する。そして車載器２３は、暗号化した、送信対象データとデジタル署名とを、更新サーバ２２に送信する。

車載器２３から、暗号化された、送信対象データとデジタル署名とを受信すると、セキュリティ確保部３５は、更新サーバ２２の秘密鍵を用いて受信した情報を復号する。次にセキュリティ確保部３５は、車載器２３の公開鍵７２を鍵管理情報７０から取得して、その公開鍵７２で、デジタル署名を復号してハッシュ値を取得する。次にセキュリティ確保部３５は、車載器２３に対応するハッシュ関数７３を鍵管理情報７０から取得し、取得したハッシュ関数７３を用いて、送信対象データのハッシュ値を算出する。そしてセキュリティ確保部３５は、算出したハッシュ値と、デジタル署名を復号して得たハッシュ値とを比較し、比較の結果が一致した場合に、車載器２３が正当な車載器２３であると判定し、車載器２３から受信したデータは改竄されていないと判定する。比較の結果が一致しない場合、セキュリティ確保部３５は、車載器２３に送信データの再送を要求する。

尚、セキュリティ確保部３５と車載器２３の間で送受信されるデータの暗号化については、共通鍵暗号と公開鍵暗号を組み合わせたハイブリッド暗号方式を用いてもよいし、種々の方法が用いられてもよい。

このように更新サーバ２２のセキュリティ確保部３５は、車載器２３の認証と車載器２３から受信した情報が改竄されていないことを確認する。

ここで、更新サーバ２２から対象車両の車載器２３に送信されるデータは、送信前にセキュリティ確保部３５によりデジタル署名が付与され、さらに暗号化されて送信されるものとする。このような送信データには、送信部３４が車載器２３に送信する更新ファイルなどが含まれる。

図８は、更新サーバ２２における更新ファイルの送信処理の動作フローを図解したフローチャートである。

図８において、先ず認証部３１は、対象車両のリモートメンテナンスに対する所有者からの同意を得たか否かを確認する（Ｓ１０１）。対象車両のリモートメンテナンスに対する所有者からの同意を得ていないと判定された場合（Ｓ１０１でＮｏ）、処理は終了する。

Ｓ１０１において、対象車両のリモートメンテナンスに対する所有者からの同意を得たと判定された場合（Ｓ１０１でＹｅｓ）、電力算出部３２は、全ての更新対象ファイルのインストール処理にかかる消費電力量の合計値を更新総消費電力として算出する（Ｓ１０２）。そして電力算出部３２は、更新総消費電力と使用可能電力量とを比較し、更新総消費電力が、対象車両のバッテリの容量のうち、更新ファイルのインストールに使用可能な最大電力量である使用可能電力量より大きいか否かを判定する（Ｓ１０３）。電力算出部３２により更新総消費電力が使用可能電力量以下であると判定された場合（Ｓ１０３でＮｏ）、処理はＳ１０５に遷移する。

一方、Ｓ１０３において、電力算出部３２により更新総消費電力が使用可能電力量より大きいと判定された場合（Ｓ１０３でＹｅｓ）、分割部３３は更新ファイルの分割を行う（Ｓ１０４）。

次に、送信部３４は、送信制御のための制御変数の初期化処理を行う（Ｓ１０５）。ここで、説明のために、分割されたグループの数をＮとし、グループ毎にそれぞれ１から昇順の番号が振られるとする。また、以下のステップＳ１０６において送信部３４が送信対象とするグループのグループ番号を示す制御変数ｎを定義し、ｎを1で初期化する。尚、更新ファイルの分割が行われていない場合にはＮの値は１となる。

次に、送信部３４は、グループ番号が変数ｎのグループに含まれる更新ファイルを車載器２３に送信する（Ｓ１０６）。

そして送信部３４は、グループ番号が変数ｎのグループに含まれる全ての更新ファイルの送信が完了したか否かを判定する（Ｓ１０７）。グループ番号が変数ｎのグループに含まれる何れかのファイルの送信が完了していないと判定した場合（Ｓ１０７でＮｏ）、送信部３４は送信処理ステータスの確認を行う（Ｓ１０８）。次に、処理はＳ１０６に戻り、グループ番号が変数ｎのグループに含まれるファイルのうち、送信が完了していない更新ファイルを車載器２３に送信する。

Ｓ１０７において、グループ番号が変数ｎのグループに含まれる全ての更新ファイルの送信が完了したと判定した場合（Ｓ１０７でＹｅｓ）、送信部３４は、グループ番号が変数ｎのグループの送信完了を車載器２３に通知する（Ｓ１０９）。そして送信部３４は、変数ｎの値をインクリメントする（Ｓ１１０）。

次に、送信部３４は、すべてのグループの送信処理が完了したか否かを判定する（Ｓ１１１）。すなわち送信部３４は、ｎの値がＮより大きいか否かを判定する。何れかのグループの送信処理が完了していないと判定された場合（Ｓ１１１でＮｏ）、すなわち、ｎの値がＮ以下の場合は、処理はＳ１０６に遷移する。

一方Ｓ１１１において、すべてのグループの送信処理が完了したと判定した場合（Ｓ１１１でＹｅｓ）、すなわちｎの値がＮより大きい場合、送信部３４はすべてのグループの送信処理が完了したと判定する。そして送信部３４は、車載器２３に適用対象の全ての更新ファイルの送信処理が完了したことを通知する（Ｓ１１２）。そして、処理は終了する。

次に、自動車２１における更新ファイルのインストール処理について説明する。
更新ファイルのインストール処理は、対象車両が停止している状態で実施される。そこで本実施形態では、対象車両が停止状態にある時間帯の履歴を記録し、履歴から車両が安定して停止することが見込まれる時間帯を予測する。そして、車両が安定して停止することが見込まれる時間帯に、車両が停止した場合に、更新ファイルのインストール処理を開始するように制御する。また、更新ファイルのインストール処理の開始前には、その時点におけるバッテリの残量が、インストール処理を行うために十分な量あるか否かが判定される。

更に、更新ファイルのインストール処理は、分割部３３によって分割された１グループ単位で行われる。また、１グループのインストール処理後、バッテリの充電が実施されたことが確認されてから、次のグループのインストール処理が開始される。よって複数のグループのインストール処理が全て完了するには、数日に跨る処理となる場合もある。例えば、３グループある場合で１週間に１回しか充電が行われない場合には、最短でも２週間と１日の日数が、すべてのファイルのインストール処理にかかることがある。

尚、更新サーバ２２からの更新ファイルのダウンロード処理と更新ファイルのインストール処理とは、時間的に隔離される。更新ソフトウェアのダウンロード処理は、インストール処理よりも電力を消費することが多いが、ダウンロード処理後、バッテリが充電されてからインストール処理を行うことで、バッテリの枯渇を軽減できる。

図９は、車載器２３の構成の一例を示す。
車載器２３は、記録部８１、状態確認部８２、残量確認部８３、インストール処理部８４、認証部８５、受信部８６、通信セキュリティ確保部８７、異常処理部８８、作業完了確認部８９、及び信頼性チェック部８０１を含む。

車載器２３は情報処理装置１０の一例である。受信部８６は受信部８の一例である。インストール処理部８４は処理部９の一例である。

記録部８１は、対象車両が停止した時間帯の履歴情報を記録する。以下の説明では、記録部８１が記録する、対象車両の停止時間帯の履歴情報を、車両履歴情報と記す。

具体的には、記録部８１は、一定期間の車両の停止時間帯と停止位置を、車両停止履歴情報として、所定の記憶領域に記憶する。図１０は、車両履歴情報の構成の一例を示す。

車両履歴情報９０は、停止時間帯９１、及び停止位置９２のデータ項目を含む。停止時間帯は、対象車両の停止時間帯を示す情報である。停止位置９２は、停止時間帯９１で示される時間帯の対象車両の位置を示す情報である。

記録部８１は、車両が停止した場合、停止した時間とそのときの車両の位置情報を、それぞれ、車両履歴情報９０の停止時間帯９１、停止位置９２に格納する。例えば、記録部８１は車両が停止する直前に停止時刻を記録し、次に車両が起動された際に起動時刻を記録し、記録した停止時刻と起動時刻から停止時間帯を算出して、停止時間帯９１に記録してもよい。また、停止時刻または起動時刻における車両の位置を例えば、車両に搭載されたＧＰＳ（Global Positioning System）などを用いて測定し、測定の結果を停止位置９２に格納してもよい。

状態確認部８２は、対象車両が、安定して停止することが見込まれる時間帯に停止しているか否かを判定する。

具体的には、先ず状態確認部８２は、車両履歴情報９０を参照して、所定の場所に定期的に車両が停止する時間帯を特定する。例えば、状態確認部８２は、車両履歴情報９０を参照し、１ヶ月間などの一定期間の間、車両が所定の場所に停止する時間帯が定期的に現れるパターンを特定する。図１０の車両履歴情報９０においては、例えば、「18:00〜9:00」の間「座標X.Y」において車両が定期的に停止されていることが記録されている。そこで、状態確認部８２は、「座標X.Y」において「18:00〜9:00」の間は定期的に車両が停止していると判定する。

尚、定期的に車両が停止する時間帯と判定されるのは、例えば5時間以上等、所定の時間幅以上のものであるとする。この所定の時間幅の値をαと記すと、αは予め所定の記憶領域に記憶されるものとする。またαは、更新ファイルのグループ毎のファイルをインストールするためにかかる時間を基に算出されてもよい。例えばαは、１グループに含まれるすべての更新ファイルをインストールするための時間よりも大きい値に設定されてもよい。

そして状態確認部８２は、定期的に車両が停止していると判定された時間帯と座標に車両が停止しているか否かを判定する。以下の説明では、この定期的に車両が停止していると判定された時間帯と座標に、車両が停止している状態を、車両が安定停止状態にあると記す。尚、車両の停止位置は若干ずれることが考えられるので、停止位置が同じであると判定する座標には所定の幅を持たせてもよい。

残量確認部８３は、現在の対象車両のバッテリの残量が、インストール処理を行うために十分に残されているかを確認する。具体的には残量確認部８３は、現在の対象車両のバッテリの残量が、使用可能電力量と基本電力量と所定の余裕値の加算値以上であるか否かを判定する。尚、所定の余裕値は0でもよい。また、使用可能電力量と基本電力量は、更新サーバの容量管理情報５０から残量確認部８３により取得されてもよい。尚、現在のバッテリの残量は、電力負荷をかけた際の電圧低下や内部抵抗の値により推測することができる。

また、残量確認部８３は、対象グループに含まれるそれぞれのファイルのインストール処理の実行前に、バッテリの電圧が正常か否かの判定を行う。具体的には、残量確認部８３は、バッテリの電圧が予め所定の記憶領域に記憶された正常値の範囲内にあるか否かを判定する。各更新ファイルのインストール処理前に、バッテリ電圧が正常か否かの判定を行うことで、インストール処理以外の不測の要因によりバッテリの残量が少なくなった場合に、インストール処理が実行されることを防ぐことができる。例えば、バッテリの容量は温度によって変化することや予期せぬエンジンの起動などが、不測の要因の一つに挙げられる。

インストール処理部８４は、更新ファイルのインストール処理を実行する。すなわち、インストール処理部８４は、更新ファイルの適用対象のＥＣＵ２４に対して、更新サーバ２２から受信した更新ファイルを送信するとともに、更新ファイルのインストール処理の実施を指示する。そして、指示を受けたＥＣＵ２４から更新ファイルのインストールの完了通知を受信すると、インストール処理部８４は、更新サーバ２２にインストールの完了通知を転送する。ここで、ＥＣＵ２４はインストールの完了通知にインストール処理後の構成情報を含ませる。この構成情報を用いて、更新サーバ２２の検証部３６は、インストールの成否確認を行う。検証部３６によりインストールは失敗したと判定された場合には、インストール処理部８４は、インストールのリトライ指示（またはロールバック指示）を検証部３６から受信する。すると、インストール処理部８４は、ＥＣＵ２４に対してインストールのリトライ（またはロールバック）を指示する。検証部３６によりインストールが成功したと判定された場合には、インストール処理部８４は、検証部３６から更新ファイルのインストールが成功した旨の通知を受信する。

認証部８５は、対象車両のリモートメンテナンスに対する所有者からの同意を得たか否かを確認する。

すなわち、認証部８５は、先ず、更新サーバ２２に対して、対象車両のリモートメンテナンスに対する所有者の事前同意があるか否かの確認要求を行う。そして、対象車両のリモートメンテナンスに対する所有者の事前同意がある旨の通知を受信した場合、認証部８５は更新ファイルのインストールの開始に当たっての所有者の同意を取得する。

インストール開始に当たっての所有者の同意の取得では、認証部８５は、所有者により事前に登録された認証方法による認証情報を取得する。例えば、事前に登録された認証方法が指紋認証（静脈認証）である場合、認証部８５は所有者に対して指紋の入力を促すメッセージを出力し、所有者の指紋を所定の入力装置（例えば指紋センサ等）を介して取得する。また、例えば、事前に登録された認証方法が音声認証である場合、認証部８５は所有者に対して音声の入力を促すメッセージを出力し、所有者の音声を所定の入力装置（例えばマイク等）を介して取得する。また、例えば、事前に登録された認証方法が画像認証である場合、認証部８５は所有者に対して画像の取得を行う旨のメッセージを出力し、所有者の画像を所定の入力装置（例えばカメラ等）を介して取得する。尚、認証方法は、更新サーバ２２が管理する同意情報４０の認証方法４４に対応するものとする。認証方法は車載器２３の所定の記憶領域に予め格納されてもよいし、リモートインストール開始に当たっての所有者の同意取得の前に、更新サーバ２２から取得されてもよい。

次に認証部８５は、同意確認情報に、所有者から取得した認証情報を含ませて、更新サーバ２２に送信する。そして認証部８５は、更新サーバ２２から認証結果を受信する。認証部８５は受信した認証結果を確認し、認証に成功したか否かの結果を確認する。認証に成功していないことを確認した場合、認証部８５はリモートメンテナンスに対する所有者からの同意を得ていないと判定する。認証に成功したことを確認した場合、認証部８５はリモートメンテナンスに対する所有者からの同意を得たと判定する。

受信部８６は、更新サーバ２２の送信部３４から送信された更新ファイルを受信する。上述したように、更新ファイルは、分割（分類）されたグループ毎に送信部３４から送信される。受信部は、分割（分類）されたグループ毎に更新ファイルを受信し、受信した更新ファイルを分割（分類）されたグループ毎に所定の記憶領域に格納する。

また、受信部は、更新サーバ２２で分割（分類）された所定のグループに含まれるすべての更新ファイルが受信済みか否かを判定する。

分割（分類）されたグループに含まれるすべての更新ファイルが受信済みか否かの判定は、更新サーバ２２からグループ毎の送信完了通知を受信したか否かを受信部８６が確認することにより行われる。受信部８６は、グループ毎の送信完了通知を受信した場合、そのグループに含まれるすべての更新ファイルが受信済みであると判定する。

受信部８６は、対象グループに含まれるすべての更新ファイルが受信済みでないと判定した場合、更新サーバ２２に更新ファイルの送信要求を送信する。ここで、受信部８６は、受信に失敗したファイルがある場合には、受信に失敗したファイルを指定して、更新サーバ２２にファイルの送信要求を行ってもよい。

通信セキュリティ確保部８７は、更新サーバ２２との通信のセキュリティを確保する。更新サーバ２２との通信のセキュリティを確保するために、通信セキュリティ確保部８７は、予め、更新サーバ２２の公開鍵、車載器２３の秘密鍵、及びハッシュ関数を所定の記憶領域に記憶しておく。更新サーバ２２の公開鍵、車載器２３の秘密鍵、及びハッシュ関数は車両の出荷前に格納される。尚、車載器２３の秘密鍵とハッシュ関数は、鍵管理情報７０の公開鍵７２とハッシュ関数７３に対応する。

そして、通信セキュリティ確保部８７は、更新サーバ２２のセキュリティ確保部３５と同様に、更新サーバ２２と車載器２３の間の通信のセキュリティを確保する。すなわち、通信セキュリティ確保部８７による、更新サーバ２２の認証、及び更新サーバ２２から受信した情報が改竄されていないことの判定も、上記のセキュリティ確保部３５による車載器２３の認証と同様にして行われる。認証に当たって、先ず更新サーバ２２のセキュリティ確保部３５は、送信対象データのハッシュ値を、ハッシュ関数を用いて算出する。次にセキュリティ確保部３５は、算出したハッシュ値を、更新サーバ２２の秘密鍵を用いて暗号化し、デジタル署名を作成する。そして更新サーバ２２のセキュリティ確保部３５は、作成したデジタル署名と送信対象データとを、車載器２３の公開鍵を用いて暗号化する。そして更新サーバ２２のセキュリティ確保部３５は、暗号化した、送信対象データとデジタル署名とを、車載器２３に送信する。

更新サーバ２２から、暗号化された、送信対象データとデジタル署名とを受信すると、通信セキュリティ確保部８７は、車載器２３の秘密鍵を用いて受信した情報を復号する。次に通信セキュリティ確保部８７は、更新サーバ２２の公開鍵を用いてデジタル署名を復号しハッシュ値を取得する。次に通信セキュリティ確保部８７は、ハッシュ関数を用いて、送信対象データのハッシュ値を算出する。そして通信セキュリティ確保部８７は、算出したハッシュ値と、デジタル署名を復号して得たハッシュ値とを比較し、比較の結果が一致した場合に、更新サーバ２２が正当であると判定し、更新サーバ２２から受信した送信対象データは改竄されていないと判定する。すなわち、通信セキュリティ確保部８７は、更新サーバ２２から送信されたデータは、正しく受信されたと判定する。一方、比較の結果が一致しなかった場合、通信セキュリティ確保部８７は、更新サーバ２２から送信されたデータは、正しく受信されなかったと判定する。

ここで、車載器２３から更新サーバ２２に送信されるデータは、送信前に通信セキュリティ確保部８７により、デジタル署名が付加され、さらに暗号化されて送信されるものとする。このような送信データには、インストール処理部８４が更新サーバ２２に送信する構成情報などが含まれる。

通信セキュリティ確保部８７は、更新サーバ２２から送信された更新ファイルが正しく受信されなかったと判定した場合、正しく受信できなかったことを示す情報と、正しく受信できなかったファイルの識別情報とを含むステータス情報を更新サーバ２２に通知する。そして、通信セキュリティ確保部８７は、更新サーバ２２から送信された更新ファイルが正しく受信されたと判定した場合、正しく受信できたことを示す情報を含むステータス情報を更新サーバ２２に通知する。

異常処理部８８は、リモートメンテナンスによるファイルの更新に失敗した場合の種々の異常処理を行う。具体的には、異常処理部８８は、リモートインストール開始時に所有者の同意を得られなかった場合に、所有者によるリモートメンテナンスの同意が得られないのでリモートメンテナンスができない旨のメッセージを出力する。また、異常処理部８８は、リモートインストール開始時に所有者の認証に失敗した場合に、所有者の認証ができないのでリモートメンテナンスができない旨のメッセージを出力する。また、異常処理部８８は、ファイルの更新処理前のバッテリの電圧が異常値を示す場合に、バッテリの残量が不足しているためリモートメンテナンスができない旨のメッセージを出力する。尚、異常処理部８８によるメッセージの出力は、次回エンジンが起動された直後に行われてもよい。また、異常処理部８８はメッセージの出力後、作業ログを更新サーバ２２に送信してもよい。

また、異常処理部８８は、ファイルの更新処理に失敗した場合には、ファイルの更新に失敗した旨のメッセージを出力する。また、重大なエラーが発生し、自動車２１の安全性が確保できない場合には、異常処理部８８は、エンジンがかからないように車両を制御してもよい。

作業完了確認部８９は、適用対象の更新ファイルのインストールが成功した場合の処理を行う。すなわち、作業完了確認部８９は、更新サーバ２２の検証部３６から適用対象の更新ファイルのインストールが成功した旨の通知を受信する。すると、作業完了確認部８９は、適用対象の更新ファイルのインストール処理が正しく完了したことを所有者に通知する。所有者に対する通知は、例えば、車載器２３の表示装置にインストールが成功した旨を表示させることにより行う。そして作業完了確認部８９は、更新ファイルのインストール処理が正しく完了したことを所有者が確認したことを示す情報、及び、更新ファイルの有効化を所有者が同意したことを示す情報を含む最終確認情報を、所有者から取得する。すると作業完了確認部８９は、最終確認情報を、エビデンスとして所定の記憶領域に記憶するとともに、ＥＣＵ２４に対して更新ファイルの有効化を指示する。また、作業完了確認部８９は、最終確認情報と一連のインストール処理の作業ログ情報を更新サーバ２２に送信する。尚作業完了確認部８９は、更新ファイルの受信処理及びインストール処理の作業ログを記録する。

信頼性チェック部８０１は、車載器２３で稼動するアプリケーションの真正性をチェックする。具体的には例えば、信頼性チェック部８０１は、予め所定の記憶領域に、車載器２３で起動する各アプリケーションの真正性を確認するためのハッシュ値を記憶しておく。そして、アプリケーションの起動時にアプリケーションのハッシュ値を取得して予め記憶しておいた真正性を確認するためのハッシュ値と比較し、ハッシュ値が一致した場合、アプリケーションは真正であると判定する。信頼性チェック部８０１による真正性のチェックの対象となるアプリケーションには、記録部８１、状態確認部８２、残量確認部８３、インストール処理部８４、及び認証部８５の機能を提供するものが含まれる。さらに信頼性チェック部８０１による真正性のチェックの対象となるアプリケーションには、受信部８６、通信セキュリティ確保部８７、異常処理部８８、及び作業完了確認部８９の機能を提供するものが含まれる。また、信頼性チェック部８０１は、インストール処理部８４と通信を行うＥＣＵ２４のアプリケーションについても同様に、ハッシュ値の比較による真正性のチェックを行う。このＥＣＵ２４のアプリケーションには、例えばＥＣＵ２４の構成情報を取得するアプリケーションが含まれる。尚、信頼性チェック部８０１の機能は、ＴＰＭにより提供されてもよい。ＴＰＭは、ハードウェア耐タンパー性をもつセキュリティチップであり、信頼性基点として、ＴＰＭがハッシュ値のチェックを行う各アプリケーションの信頼性の確保に用いることができる。

信頼性チェック部８０１により、車載器２３から更新サーバ２２に送信されるデータの信頼性を確保することができる。また例えば、信頼性チェック部８０１は、車両履歴情報９０、認証情報、同意確認情報、ステータス情報、最終確認情報、及び作業ログの真正性を保証することができる。

図１１は、車載器２３におけるインストール処理の動作フローを図解したフローチャートである。

図１１において先ず状態確認部８２は、対象車両が安定停止状態にあるか否かを判定する（Ｓ２０１）。対象車両が安定停止状態にないと判定された場合（Ｓ２０１でＮｏ）、処理はＳ２０１に戻る。

Ｓ２０１において、対象車両が安定停止状態にあると判定された場合（Ｓ２０１でＹｅｓ）、残量確認部８３は、現在の車両のバッテリの残量が、使用可能電力量と基本電力量と所定の余裕値の加算値より大きいか否かを判定する（Ｓ２０２）。現在の車両のバッテリの残量が、使用可能電力量と基本電力量と所定の余裕値の加算値以下であると判定された場合（Ｓ２０２でＮｏ）、処理は、Ｓ２０１に遷移する。ここで、現在の車両のバッテリの残量が、使用可能電力量と基本電力量と所定の余裕値の加算値以下であると判定された場合には、異常処理部８８はバッテリの残量が不足しているため、リモートインストールが実施できない旨のメッセージを表示する等してもよい。

Ｓ２０２において、現在のバッテリ残量が、使用可能電力量と基本電力量と所定の余裕値の加算値より大きいと判定された場合（Ｓ２０２でＹｅｓ）、認証部８５は、対象車両のリモートメンテナンスに対する所有者からの同意を得たか否かを確認する（Ｓ２０３）。

対象車両のリモートメンテナンスに対する所有者からの同意を得ていないと判定された場合（Ｓ２０３でＮｏ）、異常処理部８８は、異常処理を行う（Ｓ２０４）。すなわち、異常処理部８８は、対象車両のリモートメンテナンスに対する所有者からの同意を得られなかった場合に、所有者によるリモートメンテナンスの同意が得られないのでリモートメンテナンスができない旨のメッセージを出力する。また、異常処理部８８は、リモートインストール開始時に所有者の認証に失敗した場合に、所有者の認証ができないのでリモートメンテナンスができない旨のメッセージを出力する。そして処理は終了する。

一方、Ｓ２０３において、対象車両のリモートメンテナンスに対する所有者からの同意を得たと判定された場合（Ｓ２０３でＹｅｓ）、受信部８６は、分割されたグループに含まれるすべての更新ファイルが受信済みか否かを判定する（Ｓ２０５）。対象グループに含まれるすべての更新ファイルが受信済みでないと判定した場合（Ｓ２０５でＮｏ）、受信部８６は更新サーバ２２に更新ファイルの送信要求を行う（Ｓ２０６）。そして、処理はＳ２０５に遷移する。

Ｓ２０５において、受信部８６により対象グループに含まれるすべての更新ファイルが受信済みであると判定された場合（Ｓ２０５でＹｅｓ）、残量確認部８３は、バッテリの電圧が正常か否かを判定する（Ｓ２０７）。

Ｓ２０７において、バッテリの電圧が異常であると判定された場合（Ｓ２０７でＮｏ）、異常処理部８８は異常処理を実行する（Ｓ２０８）。すなわち例えば異常処理部８８は、バッテリの残量が不足しているため、リモートメンテナンスができない旨のメッセージを出力する。ここで、異常処理部８８は、グループのファイルのインストールが成功したファイルのロールバック処理を行ってもよい。そして処理は終了する。

一方、Ｓ２０７において、バッテリの電圧が正常であると判定された場合（Ｓ２０７でＹｅｓ）、インストール処理部８４は、ファイルのインストールを実行する（Ｓ２０９）。

次に、インストール処理部８４は、対象グループの全てのファイルのインストールが終了したか否かを判定する（Ｓ２１０）。対象グループのいずれかのファイルのインストールが終了していないと判定された場合（Ｓ２１０でＮｏ）、処理はＳ２０７に遷移する。

一方、Ｓ２１０において、対象グループのすべてのファイルのインストールが終了したとインストール処理部８４により判定された場合（Ｓ２１０でＹｅｓ）、処理は終了する。

尚、図１１のフローは、分割された所定のグループ毎に実施される。また、図１１のフローの開始は、更新サーバ２２から所定のグループに含まれるすべての更新ファイルの受信が完了した状態で行われてもよい。また、一つのグループのインストール処理が完了すると（例えば１回目の図１１のフローが完了すると）、次のグループのインストール処理（２回目の図１１のフロー）が実施されるまでの間に、例えば車両の走行等によりバッテリの充電が実施されるものとする。分割して更新ファイルのインストールが行われる場合、１つのグループのインストール処理が完了後に初めてエンジンが起動された際に、記録部８１は後日残りのインストール作業が予定されている旨を所有者に通知してもよい。

また、図１１のフローは、エンジン停止キーが回された瞬間に開始されてもよい。その場合、Ｓ２０３の、対象車両のリモートメンテナンスに対する所有者からの同意を得たか否かの確認において実施される、インストール開始に当たっての所有者の同意の取得は停止直後に行われてもよい。

次に、ＥＣＵ２４の構成について説明する。図１２は、本実施形態に係るＥＣＵの構成の一例を示す。図１２において、ＥＣＵ２４は、インストール部３０１、及び構成情報収集部３０２を含む。

インストール部３０１は、車載器２３から更新ファイルを含むインストール処理の実施指示を受信する。するとインストール部３０１は、受信した更新ファイルをインストールする。ただし、車載器２３から有効化の指示を受信するまでは、インストール処理部は更新の有効化（例えば、更新したソフトウェアでの起動）は行わない。

構成情報収集部３０２は、インストール部３０１による更新ファイルのインストール処理の後、ソフトウェアの構成情報を収集する。そして構成情報収集部３０２は、収集した構成情報を含むインストールの完了通知を車載器２３に送信する。

車載器２３からロールバックの指示を受けた場合にはインストール部３０１は、インストール処理における変更を破棄して、ソフトウェアを適用処理の直前の状態に戻す。そしてインストール部３０１は、作業ログを車載器２３に送信する。ここで、作業ログは、インストール部３０１によるインストール処理と、その後の有効化処理またはロールバック処理の作業ログのデータである。

車載器２３からインストールのリトライ指示を受けた場合にはインストール部３０１は、更新ファイルのインストール処理を再実施する。

尚、ロールバック処理は、更新ソフトウェアのインストール処理の開始直前のソフトウェアの状態を所定の記憶領域にバックアップ（またはスナップショットを取得）することにより実現してもよい。この場合、インストール部３０１は、車載器２３から対象ファイルのインストール指示を受信すると、先ず、更新対象ソフトウェアのバックアップを取得する。バックアップの取得が完了するとインストール部３０１は更新ファイルをインストールする。その後車載器２３からロールバックの指示を受信すると、インストール部３０１は、バックアップしたデータを戻すことにより、インストール処理開始直前の状態に更新対象ソフトウェアを復元する。

尚、本実施形態においては、車載器２３とＥＣＵ２４間の通信のセキュリティは確保されているものとする。車載器２３とＥＣＵ２４間のセキュリティが確保されていない場合には、車載器２３と更新サーバ２２の通信と同様に、通信データに署名を付与することによって、車載器２３とＥＣＵ２４間の通信のセキュリティを確保してもよい。

次に、ＥＣＵ２４での更新ファイルの有効化について説明する。ＥＣＵ２４は、読み出し用と更新処理用の２つの環境を含む。読み出し用の環境は現在有効となっているソフトウェアが稼動している環境である。更新処理用の環境は、修正ファイルのインストール処理において使用される環境である。読み出し用の環境の現在有効なソフトウェアのバージョンを（Ａ）とすると、更新処理用の環境のソフトウェアはＡのひとつ前のバージョンである（Ａ−１）となる。この（Ａ−１）のソフトウェアに対して更新ファイルのインストールが行われると、（Ａ＋１）のソフトウェアに更新される。その後、インストールの成功が確認されると、ＥＣＵ２４は更新ファイルの有効化が指示されるが、更新ファイルの有効化では、更新処理用の環境が読み出し用の環境に切り替えられ、読み出し用の環境が更新処理用の環境に切り替えられる。すると（Ａ＋１）のバージョンのソフトウェアがＥＣＵ２４で稼動することとなる。このようにしてＥＣＵ２４では、更新ファイルのインストールと有効化が行われる。

次に、更新サーバ２２の構成について説明する。図１３は、更新サーバ２２のハードウェア構成の一例を示す。

更新サーバ２２は、ＣＰＵ（Central Processing Unit）４０１、メモリ４０２、記憶装置４０３、読取装置４０４、通信インターフェース４０５、及び入出力装置４０６を含む。ＣＰＵ４０１、メモリ４０２、記憶装置４０３、読取装置４０４、通信インターフェース４０５、及び入出力装置４０６はバスを介して接続される。

ＣＰＵ４０１は、メモリ４０２を利用して上述のフローチャートの手順を記述したプログラムを実行することにより、認証部３１、電力算出部３２、分割部３３、送信部３４、セキュリティ確保部３５、及び検証部３６の一部または全部の機能を提供する。

メモリ４０２は、例えば半導体メモリであり、ＲＡＭ（Random Access Memory）領域およびＲＯＭ（Read Only Memory）領域を含んで構成される。記憶装置４０３は、例えばハードディスクである。なお、記憶装置４０３は、フラッシュメモリ等の半導体メモリであってもよい。また、記憶装置４０３は、外部記録装置であってもよい。記憶装置４０３は記憶部１の一例である。

読取装置４０４は、ＣＰＵ４０１の指示に従って着脱可能記憶媒体４５０にアクセスする。着脱可能記憶媒体４５０は、たとえば、半導体デバイス（ＵＳＢメモリ等）、磁気的作用により情報が入出力される媒体（磁気ディスク等）、光学的作用により情報が入出力される媒体（ＣＤ−ＲＯＭ、ＤＶＤ等）などにより実現される。尚、読取装置４０４は更新サーバ２２に含まれなくてもよい。

通信インターフェース４０５は、車載器２３に接続し、ＣＰＵ４０１の指示に従ってネットワークを介して、車載器２３との間でデータを送受信する。また、通信インターフェース４０５は、他の情報処理装置と接続してもよい。

入出力装置４０６は、例えば、ユーザからの指示を受け付けるデバイス、情報を表示する表示装置などである。尚、入出力装置４０６は更新サーバ２２に含まれなくてもよい。

実施形態のプログラムは、例えば、下記の形態で更新サーバ２２に提供される。
（１）記憶装置４０３に予めインストールされている。
（２）着脱可能記憶媒体４５０により提供される。
（３）プログラムサーバ（図示せず）から通信インターフェース４０５を介して提供される。

さらに、実施形態の更新サーバ２２の一部は、ハードウェアで実現してもよい。或いは、実施形態の更新サーバ２２は、ソフトウェアおよびハードウェアの組み合わせで実現してもよい。

次に、車載器２３の構成について説明する。図１４は、車載器２３のハードウェア構成の一例を示す。

車載器２３は、ＣＰＵ５０１、メモリ５０２、記憶装置５０３、読取装置５０４、通信インターフェース５０５、入出力装置５０６、及びＴＰＭ５０７を含む。ＣＰＵ５０１、メモリ５０２、記憶装置５０３、読取装置５０４、通信インターフェース５０５、入出力装置５０６、及びＴＰＭ５０７はバス等を介して接続される。

ＣＰＵ５０１は、メモリ５０２を利用して上述のフローチャートの手順を記述したプログラムを実行することにより、記録部８１、状態確認部８２、残量確認部８３、インストール処理部８４、及び認証部８５の一部または全部の機能を提供する。また、ＣＰＵ５０１は、受信部８６、通信セキュリティ確保部８７、及び異常処理部８８の一部または全部の機能を提供する。

メモリ５０２は、例えば半導体メモリであり、ＲＡＭ領域およびＲＯＭ領域を含んで構成される。記憶装置５０３は、例えばハードディスクであり、また、実施形態のプログラムを格納する。なお、記憶装置５０３は、フラッシュメモリ等の半導体メモリであってもよい。また、記憶装置５０３は、外部記録装置であってもよい。

読取装置５０４は、ＣＰＵ５０１の指示に従って着脱可能記憶媒体５５０にアクセスする。着脱可能記憶媒体５５０は、たとえば、半導体デバイス（ＵＳＢメモリ等）、磁気的作用により情報が入出力される媒体（磁気ディスク等）、光学的作用により情報が入出力される媒体（ＣＤ−ＲＯＭ、ＤＶＤ等）などにより実現される。尚、読取装置５０４は車載器２３に含まれなくてもよい。

通信インターフェース５０５は、更新サーバ２２に接続し、ＣＰＵ５０１の指示に従ってネットワークを介してデータを送受信する。また、通信インターフェース５０５は、ＥＣＵ２４に接続し、ＣＰＵ５０１の指示に従ってネットワークを介してデータを送受信する。

入出力装置５０６は、例えば、情報を表示する表示装置などである。ユーザに対する警告や更新ファイルのインストール結果は、入出力装置５０６に出力される。また例えば入出力装置５０６は、カメラ、マイク、指紋センサ、またはタッチパネル等でもよく、この入出力装置５０６を介して、所有者からのリモートメンテナンスの同意や、認証情報、最終確認情報が取得される。

ＴＰＭ５０７は、ＣＰＵ５０１で稼動するプログラムの信頼性をチェックすることが可能なセキュリティチップであり、信頼性チェック部８０１の機能の一部または全てを提供する。信頼性チェック部８０１がアプリケーションの真正性のチェックにおいて使用するハッシュ値は、ＴＰＭ５０７内の所定の記憶領域に格納される。

実施形態のプログラムは、例えば、下記の形態で車載器２３に提供される。
（１）記憶装置５０３に予めインストールされている。
（２）着脱可能記憶媒体５５０により提供される。
（３）プログラムサーバ（図示せず）または更新サーバ２２から通信インターフェース５０５を介して提供される。

さらに、実施形態の車載器２３の一部は、ハードウェアで実現してもよい。或いは、実施形態の車載器２３は、ソフトウェアおよびハードウェアの組み合わせで実現してもよい。

尚、車載器２３の機能は、ＥＣＵ２４のうちの何れかに含ませるようにしてもよい。
尚、本実施形態は、以上に述べた実施の形態に限定されるものではなく、本実施形態の要旨を逸脱しない範囲内で種々の構成または実施形態を取ることができる。

１ 記憶部
２ 受信部
３ 分類部
４ 送信部
５ 確認部
６ 算出部
７ 情報処理装置
８ 受信部
９ 処理部
１０ 情報処理装置

Claims (12)

1. コンピュータに、
   自動車に搭載された機器を制御する制御プログラムが動作する自動車から、該制御プログラムについての更新要求を受信し、
   記憶部に記憶された、前記自動車が属する車種に対応するバッテリの使用可能電力量に基づいて、前記更新要求に対応する複数の修正プログラムを複数のグループに分類し、
   前記グループ毎に分類された前記修正プログラムを前記自動車に送信する
   処理を実行させることを特徴とする情報処理プログラム。
2. 前記分類する処理は、
   前記制御プログラムを実行する制御部であって、前記自動車に搭載される該制御部における、前記制御プログラムに対する修正プログラムをインストールするために使用される予測の消費電力量の合計値が、前記使用可能電力量よりも大きい場合、前記複数の修正プログラムを複数のグループに分類する
   ことを含む
   ことを特徴とする請求項１に記載の情報処理プログラム。
3. 前記分類する処理は、
   前記消費電力量の合計値と前記使用可能電力量とに基づいて決定した数のグループに、前記複数の修正プログラムを分類する
   ことを含む
   ことを特徴とする請求項２に記載の情報処理プログラム。
4. 前記コンピュータに、さらに、
   前記複数のグループのうちの第１のグループに分類された前記修正プログラムが正常に受信されたか否かを示す確認情報を受信する
   処理を実行させ、
   前記送信する処理は、
   前記確認情報により、前記第１のグループに分類された前記修正プログラムが正常に受信されたことを確認した後に、前記複数のグループのうちの第２のグループに分類された前記修正プログラムの送信を開始する
   ことを含む
   ことを特徴とする請求項１〜３のうちいずれか１項に記載の情報処理プログラム。
5. 前記コンピュータに、さらに、
   前記制御部毎に対応付けて記憶部に記憶された、単位サイズの修正プログラムをインストールするために使用される消費電力量に基づいて、前記消費電力量の合計値を算出する
   処理を実行させることを特徴とする請求項２または３に記載の情報処理プログラム。
6. コンピュータに、
   インストール対象の自動車に対する１以上の修正プログラムを受信し、
   記憶部に記憶された、前記自動車が停止した場所と時間帯を示す履歴情報に基づいて、前記自動車が定期的に停止した場所と時間帯を特定し、
   特定した前記場所及び前記時間帯に前記自動車が停止している場合、前記自動車のバッテリ残量に応じて、受信した前記１以上の修正プログラムをインストールする
   処理を実行させることを特徴とする情報処理プログラム。
7. 前記インストールする処理は、
   前記自動車が所定の時間以上停止することが見込まれるタイミングで、前記受信した１以上の修正プログラムをインストールする
   ことを含む
   ことを特徴とする請求項６に記載の情報処理プログラム。
8. 前記インストールする処理は、
   前記自動車のバッテリ残量が所定の閾値以上である場合に、前記受信した１以上の修正プログラムをインストールする
   ことを含む
   ことを特徴とする請求項６または７に記載の情報処理プログラム。
9. 自動車に搭載された機器を制御する制御プログラムが動作する自動車から、該制御プログラムについての更新要求を受信し、
   記憶部に記憶された、前記自動車が属する車種に対応するバッテリの使用可能電力量に基づいて、前記更新要求に対応する複数の修正プログラムを複数のグループに分類し、
   前記グループ毎に分類された前記修正プログラムを前記自動車に送信する
   ことを特徴とする情報処理方法。
10. 第１情報処理装置と、該第１情報処理装置と通信可能な第２情報処理装置とを有する情報処理システムにおける情報処理方法であって、
    前記第１情報処理装置は、
    自動車に搭載された機器を制御する制御プログラムが動作する自動車から、該制御プログラムについての更新要求を受信し、
    記憶部に記憶された、前記自動車が属する車種に対応するバッテリの使用可能電力量に基づいて、前記更新要求に対応する複数の修正プログラムを複数のグループに分類し、
    前記グループ毎に分類された前記修正プログラムを前記第２情報処理装置に送信し、
    前記第２情報処理装置は、
    前記第１情報処理装置から、前記分類された修正プログラムを、前記グループ毎に受信し、
    前記制御プログラムが動作する自動車のバッテリ残量に応じて、前記グループ毎に、前記分類された修正プログラムをインストールする
    ことを特徴とする情報処理方法。
11. 自動車が属する車種に対応づけて、前記自動車のバッテリの使用可能電力量を記憶する記憶部と、
    自動車に搭載された機器を制御する制御プログラムが動作する自動車から、該制御プログラムについての更新要求を受信する受信部と、
    前記制御プログラムが動作する自動車に対応する使用可能電力量を前記記憶部から参照し、参照した該使用可能電力量に基づいて前記更新要求に対応する複数の修正プログラムを複数のグループに分類する分類部と、
    前記グループ毎に分類された前記修正プログラムを前記自動車に送信する送信部と、
    を備えることを特徴とする情報処理装置。
12. 第１情報処理装置と、該第１情報処理装置と通信可能な第２情報処理装置とを有する情報処理システムであって、
    前記第１情報処理装置は、
    自動車が属する車種に対応づけて、前記自動車のバッテリの使用可能電力量を記憶する記憶部と、
    自動車に搭載された機器を制御する制御プログラムが動作する自動車から、該制御プログラムについての更新要求を受信する受信部と、
    前記制御プログラムが動作する自動車に対応する使用可能電力量を前記記憶部から参照し、参照した該使用可能電力量に基づいて前記更新要求に対応する複数の修正プログラムを複数のグループに分類する分類部と、
    前記グループ毎に分類された前記修正プログラムを前記第２情報処理装置に送信する送信部と、
    を備え、
    前記第２情報処理装置は、
    前記第１情報処理装置から、前記分類された修正プログラムを、前記グループ毎に受信する受信部と、
    前記制御プログラムが動作する自動車のバッテリ残量に応じて、前記グループ毎に、前記分類された修正プログラムをインストールする処理部と、
    を備える
    ことを特徴とする情報処理システム。

Images