(57)【要約】【課題】ネットワークに接続された端末のソフトウェアの更新や復元を効率よく行う。【解決手段】実施形態の更新制御装置は、第１通信部と、第２通信部と、制御部と、を備える。第１通信部は、ソフトウェアのブロックごとのパッチデータと、該パッチデータを用いて更新されたソフトウェアをブロックごとに認証するためのブロックごとの第１認証用データとを、ネットワークの外部のサーバから受信する。第２通信部は、ブロックごとに、パッチデータと第１認証用データとをネットワークを介して端末に送信し、ブロックごとの更新結果を端末からネットワークを介して受信する。制御部は、ソフトウェアのＭブロック目（ただしＭ＞１）の認証失敗を示す更新結果を端末から受信した場合に、パッチデータを用いてソフトウェアの１ブロック目からＭ−１ブロック目までを復元するロールバック処理を端末に要求する。【選択図】図３
2019036238.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークに接続された端末のソフトウェアの更新を制御する更新制御装置であって、
前記ソフトウェアのブロックごとのパッチデータと、該パッチデータを用いて更新された前記ソフトウェアを前記ブロックごとに認証するための前記ブロックごとの第１認証用データとを、前記ネットワークの外部のサーバから受信する第１通信部と、
前記ブロックごとに、前記パッチデータと前記第１認証用データとを前記ネットワークを介して前記端末に送信し、前記ブロックごとの更新結果を前記端末から前記ネットワークを介して受信する第２通信部と、
前記ソフトウェアのＭブロック目（ただしＭ＞１）の認証失敗を示す前記更新結果を前記端末から受信した場合に、前記パッチデータを用いて前記ソフトウェアの１ブロック目からＭ−１ブロック目までを復元するロールバック処理を前記端末に要求する制御部と、
を備える更新制御装置。
【請求項２】
前記パッチデータは、更新前の前記ソフトウェアと更新後の前記ソフトウェアとを用いて排他的論理和演算を利用した処理を行うことで前記ブロックごとに得られるデータである
請求項１に記載の更新制御装置。
【請求項３】
前記第２通信部は、前記制御部が前記ロールバック処理を前記端末に要求した場合に、前記ソフトウェアの１ブロック目からＭ−１ブロック目までに対応する前記パッチデータを、前記ネットワークを介して前記端末に送信する
請求項１または２に記載の更新制御装置。
【請求項４】
前記第２通信部は、前記制御部が前記ロールバック処理を前記端末に要求した場合に、更新前の前記ソフトウェアを前記ブロックごとに認証するための前記ブロックごとの第２認証用データのうち、前記ソフトウェアの１ブロック目からＭ−１ブロック目までに対応する前記第２認証用データを、前記ネットワークを介して前記端末にさらに送信する
請求項３に記載の更新制御装置。
【請求項５】
前記端末は、前記更新制御装置から受信した前記パッチデータを一時記憶し、前記制御部から前記ロールバック処理が要求された場合に、一時記憶した前記パッチデータのうち、前記ソフトウェアの１ブロック目からＭ−１ブロック目までに対応する前記パッチデータを用いて前記ソフトウェアの１ブロック目からＭ−１ブロック目までを復元する
請求項１または２に記載の更新制御装置。
【請求項６】
前記ネットワークは車載ネットワークであり、
前記端末は前記車載ネットワークに接続された電子制御装置である
請求項１乃至５のいずれか一項に記載の更新制御装置。
【請求項７】
ネットワークを介して更新制御装置と通信する端末であって、
ソフトウェアを記憶する記憶部と、
前記ソフトウェアのブロックごとに、パッチデータと、該パッチデータを用いて更新された前記ソフトウェアのブロックを認証するための第１認証用データとを、前記ネットワークを介して前記更新制御装置から受信する通信部と、
前記ソフトウェアのブロックごとに、前記パッチデータを適用するパッチ適用部と、
前記ソフトウェアのブロックごとに、前記第１認証用データを用いて前記パッチデータを適用した前記ソフトウェアの認証を行う認証部と、を備え、
前記ソフトウェアのＭブロック目（ただしＭ＞１）の認証に失敗した場合に、前記パッチ適用部は、前記パッチデータを用いて前記ソフトウェアの１ブロック目からＭ−１ブロック目までを復元する
端末。
【請求項８】
ネットワークに接続された端末のソフトウェアの更新を制御する更新制御方法であって、
前記ソフトウェアのブロックごとのパッチデータと、該パッチデータを用いて更新された前記ソフトウェアを前記ブロックごとに認証するための前記ブロックごとの第１認証用データとを、前記ネットワークの外部のサーバから受信し、
前記ブロックごとに、前記パッチデータと前記第１認証用データとを前記ネットワークを介して前記端末に送信し、
前記ブロックごとの更新結果を前記端末から前記ネットワークを介して受信し、
前記ソフトウェアのＭブロック目（ただしＭ＞１）の認証失敗を示す前記更新結果を前記端末から受信した場合に、前記パッチデータを用いて前記ソフトウェアの１ブロック目からＭ−１ブロック目までを復元するロールバック処理を前記端末に要求する
更新制御方法。
【請求項９】
ネットワークに接続された端末のソフトウェアの更新を制御するコンピュータに、
前記ソフトウェアのブロックごとのパッチデータと、該パッチデータを用いて更新された前記ソフトウェアを前記ブロックごとに認証するための前記ブロックごとの第１認証用データとを、前記ネットワークの外部のサーバから受信する機能と、
前記ブロックごとに、前記パッチデータと前記第１認証用データとを前記ネットワークを介して前記端末に送信し、前記ブロックごとの更新結果を前記端末から前記ネットワークを介して受信する機能と、
前記ソフトウェアのＭブロック目（ただしＭ＞１）の認証失敗を示す前記更新結果を前記端末から受信した場合に、前記パッチデータを用いて前記ソフトウェアの１ブロック目からＭ−１ブロック目までを復元するロールバック処理を前記端末に要求する機能と、
を実現させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、更新制御装置、端末、更新制御方法およびプログラムに関する。
【背景技術】
【０００２】
端末のソフトウェアを更新する技術として、更新前後のソフトウェアの差分に相当するパッチデータを端末に配信し、端末が記憶するソフトウェアにパッチデータを適用することで該ソフトウェアを更新する技術が広く知られている。ソフトウェアに対するパッチデータの適用は、所定サイズのブロックごとに行われることが多い。ここで、更新の途中で何らかのトラブルが生じた場合は、すでにパッチを適用したブロックを元の状態に復元することが求められる。このソフトウェアの復元のため、従来は、更新用のパッチデータとは異なる復元用のパッチデータを端末に配信する必要があり、効率が悪いという問題があった。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１６−１７０７４０号公報
【特許文献２】特開２０１２−６９１３１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
本発明が解決しようとする課題は、ネットワークに接続された端末のソフトウェアの更新や復元を効率よく行うことができる更新制御装置、端末、更新制御方法およびプログラムを提供することである。
【課題を解決するための手段】
【０００５】
実施形態の更新制御装置は、ネットワークに接続された端末のソフトウェアの更新を制御する更新制御装置であって、第１通信部と、第２通信部と、制御部と、を備える。第１通信部は、前記ソフトウェアのブロックごとのパッチデータと、該パッチデータを用いて更新された前記ソフトウェアを前記ブロックごとに認証するための前記ブロックごとの第１認証用データとを、前記ネットワークの外部のサーバから受信する。第２通信部は、前記ブロックごとに、前記パッチデータと前記第１認証用データとを前記ネットワークを介して前記端末に送信し、前記ブロックごとの更新結果を前記端末から前記ネットワークを介して受信する。制御部は、前記ソフトウェアのＭブロック目（ただしＭ＞１）の認証失敗を示す前記更新結果を前記端末から受信した場合に、前記パッチデータを用いて前記ソフトウェアの１ブロック目からＭ−１ブロック目までを復元するロールバック処理を前記端末に要求する。
【図面の簡単な説明】
【０００６】
【図１】ＦＷ更新システムの概要を示すシステム構成図。
【図２】更新用ファイルの一例を示す図。
【図３】更新制御装置の機能的な構成例を示すブロック図。
【図４】記憶部の構成例を示す図。
【図５】ＦＷ管理テーブルの一例を示す図。
【図６】第１実施形態に係るＥＣＵの機能的な構成例を示すブロック図。
【図７】更新用ファイルダウンロード処理を説明するシーケンス図。
【図８】ＦＷ更新前処理を説明するシーケンス図。
【図９】ＦＷ更新処理（更新成功）を説明するシーケンス図。
【図１０】ＦＷ更新処理（１ブロック目で更新失敗）を説明するシーケンス図。
【図１１】第１実施形態のＦＷ更新処理（Ｍブロック目で更新失敗）を説明するシーケンス図。
【図１２】第１実施形態のロールバック処理を説明するシーケンス図。
【図１３】第２実施形態に係るＥＣＵの機能的な構成例を示すブロック図。
【図１４】第２実施形態のＦＷ更新処理（Ｍブロック目で更新失敗）を説明するシーケンス図。
【図１５】第２実施形態のロールバック処理を説明するシーケンス図。
【図１６】更新制御装置のハードウェア構成例を示すブロック図。
【発明を実施するための形態】
【０００７】
以下、実施形態の更新制御装置、端末、更新制御方法およびプログラムについて、図面を参照して説明する。実施形態の更新制御装置は、ネットワークに接続された端末のソフトウェアの更新を制御するものである。以下では、ネットワークの一例として自動車に搭載された車載ネットワーク、端末の一例として車載ネットワークに接続された電子制御ユニット（ＥＣＵ：Electronic  Control  Unit）、端末のソフトウェアとしてＥＣＵのファームウェア（以下、「ＦＷ」と表記する）を挙げ、ＥＣＵのＦＷを更新するためのＦＷ更新システムへの適用例を例示する。ただし、適用可能なシステムはこの例に限らない。本発明は、ネットワークに接続された端末のソフトウェアを更新する様々なシステムに対して広く適用可能である。
【０００８】
＜第１実施形態＞
図１は、本実施形態に係るＦＷ更新システムの概要を示すシステム構成図である。車載ネットワーク１は、ＣＡＮ（Controller  Area  Network）バスなどのネットワークバス２に接続された複数のＥＣＵ２０と、ネットワークバス２を介してこれらＥＣＵ２０と接続された更新制御装置１０とを備える。更新制御装置１０は、インターネットなどの外部ネットワーク３に接続する機能を有し、この外部ネットワーク３を介してＦＷ提供サーバ３０と通信可能に接続される。
【０００９】
一般的な車載ネットワーク１は、異なるネットワークバス２に各々接続されたＥＣＵ２０間でやり取りされるメッセージの転送や車外と車内のデータ転送などを行う機能を持ったゲートウェイと呼ばれる装置を備える。本実施形態の更新制御装置１０は、一例として、このゲートウェイの機能を拡張することにより実現することができる。ゲートウェイとは異なる更新制御装置１０を車載ネットワーク１のネットワークバス２に接続する構成であってもよい。
【００１０】
ＦＷ提供サーバ３０は、更新制御装置１０からの要求に応じて、ＥＣＵ２０が記憶しているＦＷを更新するための更新用ファイル５０を生成し、外部ネットワーク３を介して更新制御装置１０に送信する。以下では、更新前のＦＷを「現ＦＷ」と表記し、更新後のＦＷを「新ＦＷ」と表記する。
【００１１】
図２は、更新用ファイル５０の一例を示す図である。更新用ファイル５０は、例えば図２に示すように、ヘッダ情報５１、パッチ情報５２、認証情報５３および署名５４を含む。
【００１２】
ヘッダ情報５１は、例えば、新ＦＷと現ＦＷのバージョン情報、新ＦＷと現ＦＷのデータ長さやブロック数、ブロックごとのパッチデータの長さなどの情報を含む。ブロックとは、所定の長さ（ブロックサイズ）のバイトまたはビットの並びを１まとまりとしたデータ単位を表す。
【００１３】
パッチ情報５２は、現ＦＷを新ＦＷに更新するためのブロックごとのパッチデータを含む。本実施形態では、ブロックごとのパッチデータは既知のデータ圧縮方式に従って圧縮された状態で更新用ファイル５０に格納されるものとする。すなわち、パッチ情報５２は、ブロックごとのパッチデータの各々を圧縮したものの集合である。
【００１４】
認証情報５３は、現ＦＷから更新された新ＦＷをブロックごとに認証するためのブロックごとの認証用データ（第１認証用データ）を含む。本実施形態では、認証用データの一例としてメッセージ認証符号（ＭＡＣ：Message  Authentication  Code）を用いる例を例示するが、これに限らない。
【００１５】
署名５４は、ヘッダ情報５１、パッチ情報５２および認証情報５３に対するデジタル署名である。更新制御装置１０は、ＦＷ提供サーバ３０の公開鍵を用いてこの署名５４の認証を行うことにより、ＦＷ提供サーバ３０から外部ネットワーク３を介して受信した更新用ファイル５０に含まれるヘッダ情報５１、パッチ情報５２および認証情報５３の正当性を確認することができる。
【００１６】
ブロックごとのパッチデータは、パッチ生成アルゴリズムＡ１により生成される。本実施形態で使用するパッチ生成アルゴリズムＡ１は、例えば、排他的論理和演算を利用して、現ＦＷと新ＦＷとからブロックごとのパッチデータを生成する。現ＦＷのブロック数と新ＦＷのブロック数が異なる場合は、ブロック数が少ない方の末尾に０ｘｆｆを充填し、双方のブロック数を一致させる。このときの双方で一致したブロック数をＮとする。パッチ生成アルゴリズムＡ１は、１ブロック目からＮブロック目まで、現ＦＷと新ＦＷの双方の対象ブロックを取り出して排他的論理和演算を利用した処理を繰り返すことにより、Ｎブロック分のパッチデータを生成する。
【００１７】
このように生成されたブロックごとのパッチデータは、現ＦＷの対象ブロックに適用することで、このブロックを新ＦＷの対象ブロックに更新できるとともに、新ＦＷの対象ブロックに適用することで、このブロックを現ＦＷの対象ブロックに復元できるという特徴がある。すなわち、同じパッチデータを用いて、現ＦＷから新ＦＷへの更新と、新ＦＷから現ＦＷへの復元とを行うことができる。本実施形態の場合、パッチデータの適用とは、現ＦＷの対象ブロックまたは新ＦＷの対象ブロックとパッチデータとを用いて排他的論理和演算を利用した処理を行うことを意味する。
【００１８】
ブロックごとの認証用データは、ＭＡＣ生成アルゴリズムＡ２により生成される。ＭＡＣ生成アルゴリズムＡ２は、ＥＣＵ２０との間で共有される秘密鍵を用いて、新ＦＷの各ブロックからブロックごとの新ＦＷ認証用ＭＡＣを生成する。すなわち、ＭＡＣ生成アルゴリズムＡ２は、１ブロック目からＮブロック目まで、新ＦＷの対象ブロックを取り出してＭＡＣを計算する処理を繰り返すことにより、Ｎブロック分の新ＦＷ認証用ＭＡＣを生成する。
【００１９】
図３は、更新制御装置１０の機能的な構成例を示すブロック図である。更新制御装置１０は、例えば図３に示すように、車外通信部１１（第１通信部）と、車内通信部１２（第２通信部）と、署名認証部１３と、記憶部１４と、制御部１５とを備える。
【００２０】
車外通信部１１は、外部ネットワーク３を介してＦＷ提供サーバ３０と通信する。車外通信部１１によるＦＷ提供サーバ３０との通信には、例えば、更新確認要求の送信、更新確認応答の受信、更新用ファイル生成要求の送信、更新用ファイル５０の受信、署名認証確認応答の送信などが含まれる。
【００２１】
車内通信部１２は、車載ネットワーク１のネットワークバス２を介してＥＣＵ２０と通信する。車内通信部１２によるＥＣＵ２０との通信には、例えば、ＦＷ更新要求の送信、更新可能応答の受信、更新用ファイル５０のヘッダ情報５１の送信、設定完了応答の受信、ブロックごとのパッチデータおよび新ＦＷ認証用ＭＡＣの送信、ブロックごとの更新結果の受信、ロールバック要求の送信、ロールバック可能応答の受信、ロールバックに必要なパッチデータおよび現ＦＷ認証用ＭＡＣ（第２認証用データ）の送信、ロールバック時のＭＡＣ認証確認応答の受信、上書き指示の送信、上書き完了応答の受信などが含まれる。
【００２２】
車内通信部１２がＥＣＵ２０から受信するＦＷのブロックごとの更新結果は、ＦＷのブロックごとの更新が成功したか否かを示す情報である。本実施形態では、この更新結果として、新ＦＷ認証用ＭＡＣを用いたＭＡＣ認証に失敗したことを示すＭＡＣ認証失敗応答と、新ＦＷのブロックデータで現ＦＷのブロックデータを上書きして当該ブロックのＦＷ更新が完了したことを示す上書き完了応答とがある。新ＦＷ認証用ＭＡＣを用いたＭＡＣ認証に成功した場合、ＥＣＵ２０から更新制御装置１０に対してＭＡＣ認証成功応答が送信され、これに応じて、更新制御装置１０からＥＣＵ２０に対して上書き指示が送信される。この上書き指示に応じてＥＣＵ２０においてブロックデータの上書きによるＦＷの更新が行われ、更新が完了すると、ＥＣＵ２０から更新制御装置１０に対して上書き完了応答が送信される。
【００２３】
署名認証部１３は、ＦＷ提供サーバ３０の公開鍵を用いて、ＦＷ提供サーバ３０から送信された更新用ファイル５０に含まれる署名５４の認証を行う。署名認証部１３による署名５４の認証に成功すると、ＦＷ提供サーバ３０から送信された更新用ファイル５０が記憶部１４に一時記憶され、車外通信部１１からＦＷ提供サーバ３０に対して署名認証確認応答が送信される。一方、署名認証部１３による署名５４の認証に失敗した場合は、ＦＷ提供サーバ３０から送信された更新用ファイル５０は破棄される。
【００２４】
記憶部１４は、例えば図４に示すように、更新用ファイル記憶部１４ａと、ＭＡＣ記憶部１４ｂとを含む。更新用ファイル記憶部１４ａは、ＦＷ提供サーバ３０から送信された更新用ファイル５０を一時記憶する。ＭＡＣ記憶部１４ｂは、更新が正常に完了した新ＦＷに対応するブロックごとの新ＦＷ認証用ＭＡＣを、その後のＦＷ更新時におけるロールバック処理に備えて、現ＦＷ認証用ＭＡＣとして記憶する。
【００２５】
制御部１５は、車載ネットワーク１のネットワークバス２に接続された全てのＥＣＵ２０のＦＷの状態管理および更新制御を行う。ＥＣＵ２０のＦＷの状態管理には、例えば図５に示すようなＦＷ管理テーブル１６が用いられる。このＦＷ管理テーブル１６は、車載ネットワーク１のネットワークバス２に接続された全てのＥＣＵ２０について、そのＥＣＵ２０の識別情報である「ＥＣＵ＿ＩＤ」に対応付けて、そのＥＣＵ２０の現ＦＷの名前およびバージョンを示す「バージョン情報」、そのＥＣＵ２０の現ＦＷ認証用ＭＡＣがＭＡＣ記憶部１４ｂのどこに記憶されているかを示す「ＭＡＣ保存先」、そのＥＣＵ２０に対応する更新用ファイル５０が更新用ファイル記憶部１４ａのどこに一時記憶されているかを示す「ファイル保存先」、および、そのＥＣＵ２０のＦＷ更新が可能な状態であるか否かを示す「更新可能フラグ」を格納するデータ構造となっている。
【００２６】
制御部１５は、図５に示すようなＦＷ管理テーブル１６を用いてＥＣＵ２０のＦＷの状態管理を行いながら、上述の各種要求や応答、指示などを生成して、車外通信部１１からＦＷ提供サーバ３０、あるいは車内通信部１２からＥＣＵ２０へと送信させることにより、ＥＣＵ２０のＦＷの更新制御を行う。ＥＣＵ２０のＦＷの更新制御の詳細は後述する。
【００２７】
図６は、ＥＣＵ２０の機能的な構成例を示すブロック図である。ＥＣＵ２０は、例えば図６に示すように、通信部２１と、パッチ解凍部２２と、パッチ適用部２３と、ブロックデータ一時記憶部２４と、ＭＡＣ認証部２５と、上書き部２６と、ＦＷ記憶部２７とを備える。
【００２８】
通信部２１は、車載ネットワーク１のネットワークバス２を介して更新制御装置１０と通信する。通信部２１による更新制御装置１０との通信には、ＦＷ更新要求の受信、更新可能応答の送信、更新用ファイル５０のヘッダ情報５１の受信、設定完了応答の送信、ブロックごとのパッチデータおよび新ＦＷ認証用ＭＡＣの受信、ブロックごとの更新結果（ＭＡＣ認証失敗応答、あるいは、ＭＡＣ認証成功応答および上書き完了応答）の送信、ロールバック要求の受信、ロールバック可能応答の送信、ロールバックに必要なパッチデータおよび現ＦＷ認証用ＭＡＣの受信、ロールバック時のＭＡＣ認証確認応答の送信、上書き指示の受信、上書き完了応答の送信などが含まれる。
【００２９】
パッチ解凍部２２は、更新制御装置１０から送信されて通信部２１が受信したブロックごとのパッチデータ（圧縮されたパッチデータ）を解凍する。パッチ解凍部２２により解凍されたパッチデータは、パッチ適用部２３に渡される。
【００３０】
パッチ適用部２３は、ＦＷ更新時においては、パッチ解凍部２２から受け取ったパッチデータを用いて、新ＦＷのブロックデータを生成する。すなわち、パッチ適用部２３は、ＦＷ記憶部２７に記憶されている現ＦＷの対象ブロックを読み出し、この現ＦＷの対象ブロックとパッチデータとを用いて排他的論理和演算を利用した処理を行って、新ＦＷのブロックデータを生成する。また、パッチ適用部２３は、ロールバック時においては、パッチ解凍部２２から受け取ったパッチデータを用いて、現ＦＷのブロックデータを生成する。すなわち、パッチ適用部２３は、ＦＷ記憶部２７に記憶されている新ＦＷの対象ブロックを読み出し、この新ＦＷの対象ブロックとパッチデータとを用いて排他的論理和演算を利用した処理を行って、現ＦＷのブロックデータを生成する。パッチ適用部２３により生成された新ＦＷまたは現ＦＷのブロックデータは、ブロックデータ一時記憶部２４に格納され、一時的に記憶される。
【００３１】
ＭＡＣ認証部２５は、ＦＷ更新時においては、更新制御装置１０から送信されて通信部２１が受信したブロックごとの新ＦＷ認証用ＭＡＣを用いて、ブロックデータ一時記憶部２４に一時的に記憶された新ＦＷのブロックデータに対するＭＡＣ認証を行う。また、ＭＡＣ認証部２５は、ロールバック時においては、更新制御装置１０から送信されて通信部２１が受信したブロックごとの現ＦＷ認証用ＭＡＣを用いて、ブロックデータ一時記憶部２４に一時的に記憶された現ＦＷのブロックデータに対するＭＡＣ認証を行う。ＭＡＣ認証部２５によるＭＡＣ認証に成功した場合は、通信部２１から更新制御装置１０に対してＭＡＣ認証成功応答が送信され、ＭＡＣ認証に失敗した場合は、通信部２１から更新制御装置１０に対してＭＡＣ認証失敗応答が送信される。
【００３２】
上書き部２６は、更新制御装置１０から送信されて通信部２１が受信した上書き指示に応じて、ブロックデータ一時記憶部２４に一時記憶されているブロックデータを読み出し、ＦＷ記憶部２７に記憶されている対象ブロックをブロックデータ一時記憶部２４から読み出したブロックデータで上書きする。これにより、ＦＷ更新時においてはＦＷ記憶部２７に記憶されている現ＦＷがブロックごとに新ＦＷに更新され、ロールバック時においては復元の対象となるブロックが新ＦＷから現ＦＷに復元される。
【００３３】
次に、本実施形態に係るＦＷ更新システムの動作について説明する。まず、更新制御装置１０とＦＷ提供サーバ３０とにより行われる更新用ファイルダウンロード処理について、図７のシーケンス図に沿って説明する。この図７のシーケンス図で示す更新用ファイルダウンロード処理は、予め定めたタイミングあるいは更新制御装置１０の制御部１５が所定の割り込みを受けたタイミングで実施される。
【００３４】
まず、更新制御装置１０の制御部１５は、ＦＷ管理テーブル１６を参照して各ＥＣＵ２０の現ＦＷのバージョン情報などを含むＥＣＵ構成情報を生成し、車外通信部１１に渡す。そして、車外通信部１１が、このＥＣＵ構成情報を付加した更新確認要求をＦＷ提供サーバ３０に送信する（ステップＳ１０１）。ＦＷ提供サーバ３０は、更新制御装置１０から受信した更新確認要求に応じて、いずれかのＥＣＵ２０に対応する新ＦＷの有無を確認し（ステップＳ１０２）、その結果を更新確認応答として更新制御装置１０に送信する（ステップＳ１０３）。ここでは、車載ネットワーク１内のあるＥＣＵ２０に対応する新ＦＷがあるものとして説明する。
【００３５】
新ＦＷがあることを示す更新確認応答を受信すると、更新制御装置１０の車外通信部１１は、制御部１５の制御のもとで、更新用ファイル生成要求をＦＷ提供サーバ３０に送信する（ステップＳ１０４）。ＦＷ提供サーバ３０は、更新制御装置１０から受信した更新用ファイル生成要求に応じて、上述の更新用ファイル５０を生成し（ステップＳ１０５）、生成した更新用ファイル５０を更新制御装置１０に送信する（ステップＳ１０６）。この更新用ファイル５０は、更新制御装置１０の車外通信部１１により受信される。
【００３６】
次に、更新制御装置１０の署名認証部１３が、ＦＷ提供サーバ３０の公開鍵を用いて、車外通信部１１により受信された更新用ファイル５０に含まれる署名５４の認証を行う（ステップＳ１０７）。ここでは、署名認証部１３による署名認証が成功したものとして説明する。署名認証部１３による署名認証が成功すると、制御部１５の制御のもとで、車外通信部１１により受信された更新用ファイル５０が記憶部１４の更新用ファイル記憶部１４ａに保存され（ステップＳ１０８）、車外通信部１１からＦＷ提供サーバ３０に署名認証確認応答が送信される（ステップＳ１０９）。
【００３７】
このとき、更新制御装置１０の制御部１５は、ＦＷ管理テーブル１６の「ファイル保存先」に更新用ファイル５０の保存先へのパス（保存先のアドレス）を格納するとともに、ＦＷ管理テーブル１６の「更新可能フラグ」をＦＷ更新が可能な状態であることを示す値に更新する。なお、署名認証部１３による署名認証に失敗した場合は、ＦＷ提供サーバ３０から送信された更新用ファイル５０は更新用ファイル記憶部１４ａに保存されずに破棄される。
【００３８】
次に、更新制御装置１０とＥＣＵ２０とにより行われるＦＷ更新前処理について、図８のシーケンス図に沿って説明する。この図８のシーケンス図で示すＦＷ更新前処理は、ＦＷ管理テーブル１６の「更新可能フラグ」が更新可能な状態（つまり、更新用ファイル５０が記憶部１４の更新用ファイル記憶部１４ａに一時記憶されている状態）であることを示す値となっているＥＣＵ２０を対象として、例えば、車載ネットワーク１を搭載した自動車がＦＷ更新できる状態となったタイミングで開始される。自動車がＦＷ更新できる状態となったか否かを判定する方法としては、例えば、ＦＷ更新が可能なＥＣＵ２０があること、ＦＷ更新時には自動車を停止させることが望ましいことなどを、自動車内部のコンソールによる表示などでドライバに伝え、ボタン操作などでＦＷ更新の指示を受けた場合に、自動車がＦＷ更新できる状態となったと判断する方法などがある。
【００３９】
まず、更新制御装置１０の制御部１５は、ＦＷ管理テーブル１６を参照して「更新可能フラグ」が更新可能な状態となっているＥＣＵ２０を特定し、このＥＣＵ２０のＥＣＵ＿ＩＤを車内通信部１２に渡す。そして、車内通信部１２が、例えば制御部１５から渡されたＥＣＵ＿ＩＤを宛先としたＦＷ更新要求をネットワークバス２に送出することにより、ＦＷ更新の対象となるＥＣＵ２０に対してＦＷ更新要求を送信する（ステップＳ２０１）。ＦＷ更新要求を受信したＥＣＵ２０は、更新可能応答を更新制御装置１０に送信し（ステップＳ２０２）、ＦＷ更新状態に入る。
【００４０】
ＥＣＵ２０から送信された更新可能応答が更新制御装置１０の車内通信部１２により受信されると、更新制御装置１０の制御部１５は、記憶部１４の更新用ファイル記憶部１４ａに一時記憶されている更新用ファイル５０を読み出して、その更新用ファイル５０のヘッダ情報５１を車内通信部１２からＥＣＵ２０に送信させる（ステップＳ２０３）。更新用ファイル５０のヘッダ情報５１を受信したＥＣＵ２０は、このヘッダ情報５１に基づいて、ＦＷ更新に必要な各種の制御パラメータを設定し（ステップＳ２０４）、制御パラメータの設定が完了すると、設定完了応答を更新制御装置１０に送信する（ステップＳ２０５）。
【００４１】
次に、更新制御装置１０とＥＣＵ２０とにより行われるＦＷ更新処理について、図９乃至図１１のシーケンス図に沿って説明する。これら図９乃至図１１のシーケンス図で示すＦＷ更新処理は、更新制御装置１０がＥＣＵ２０から設定完了応答を受信した場合に開始される。
【００４２】
まず、ＦＷ更新に成功する場合の例を図９のシーケンス図を用いて説明する。ＦＷ更新に成功する場合は、ＦＷの最初のブロックである１ブロック目から最後のブロックであるＮブロック目まで、図９のステップＳ３０１からステップＳ３０９までの対象ブロックごとの処理が繰り返される。
【００４３】
すなわち、まず更新制御装置１０の制御部１５の制御のもとで、更新制御装置１０の車内通信部１２からＥＣＵ２０に対して、対象ブロックのパッチデータと新ＦＷ認証用ＭＡＣが送信される（ステップＳ３０１）。ＥＣＵ２０は、更新制御装置１０から送信された対象ブロックのパッチデータと新ＦＷ認証用ＭＡＣを通信部２１により受信すると、対象ブロックのパッチデータをパッチ解凍部２２により解凍する（ステップＳ３０２）。そして、パッチ適用部２３が、ＦＷ記憶部２７に記憶されている現ＦＷの対象ブロックのブロックデータを読み出して、このブロックデータに対して解凍した対象ブロックのパッチデータを適用することにより、新ＦＷの対象ブロックのブロックデータを生成し（ステップＳ３０３）、生成したブロックデータをブロックデータ一時記憶部２４に格納する（ステップＳ３０４）。
【００４４】
次に、ＭＡＣ認証部２５が、対象ブロックの新ＦＷ認証用ＭＡＣを用いて、ブロックデータ一時記憶部２４に一時記憶された新ＦＷのブロックデータに対するＭＡＣ認証を行う（ステップＳ３０５）。ここでは、新ＦＷのブロックデータに対するＭＡＣ認証に成功したものとする。新ＦＷのブロックデータに対するＭＡＣ認証に成功すると、ＥＣＵ２０の通信部２１から更新制御装置１０に対してＭＡＣ認証成功応答が送信される（ステップＳ３０６）。
【００４５】
更新制御装置１０の車内通信部１２は、ＥＣＵ２０から送信されたＭＡＣ認証成功応答を受信すると、制御部１５の制御のもとで、上書き指示をＥＣＵ２０に対して送信する（ステップＳ３０７）。ＥＣＵ２０は、更新制御装置１０から送信された上書き指示を通信部２１により受信すると、ブロックデータ一時記憶部２４に一時記憶されている新ＦＷのブロックデータを上書き部２６により読み出して、ＦＷ記憶部２７に記憶されている現ＦＷの対象ブロックを、ブロックデータ一時記憶部２４から読み出したブロックデータで上書きする（ステップＳ３０８）。そして、通信部２１から更新制御装置１０に対して上書き完了応答を送信する（ステップＳ３０９）。
【００４６】
ＦＷ更新に成功する場合は、以上のステップＳ３０１からステップＳ３０９の処理が、ＦＷの１ブロック目からＮブロック目まで繰り返される。そして、Ｎブロック目を対象ブロックとする処理が終了すると、ＥＣＵ２０は、ＦＷ更新状態から抜けて通常動作に復帰する（ステップＳ３１０）。また、更新制御装置１０の制御部１５は、後のＦＷ更新時においてロールバック処理が必要になった場合に備えて、１ブロック目からＮブロック目までの新ＦＷ認証用ＭＡＣを現ＦＷ認証用ＭＡＣとして、記憶部１４のＭＡＣ記憶部１４ｂに格納し記憶させる（ステップＳ３１１）。そして、更新制御装置１０の制御部１５は、ＦＷ管理テーブル１６のＦＷ更新を行ったＥＣＵ２０に対応する「バージョン情報」を新ＦＷのバージョンを示す値に更新し（ステップＳ３１２）、処理を終了する。
【００４７】
次に、ＦＷの１ブロック目で更新に失敗（ＭＡＣ認証に失敗）した場合の例を図１０のシーケンス図を用いて説明する。なお、図１０のステップＳ４０１からステップＳ４０５までの処理は、１ブロック目を対象ブロックとしたときの図９のステップＳ３０１からステップＳ３０５までの処理と同様であるため、詳細な説明は省略する。ただし、ここでは、ステップＳ４０５における新ＦＷの１ブロック目のブロックデータに対するＭＡＣ認証に失敗したものとする。
【００４８】
新ＦＷの１ブロック目のブロックデータに対するＭＡＣ認証に失敗すると、ＥＣＵ２０は、通信部２１から更新制御装置１０に対してＭＡＣ認証失敗応答を送信した後（ステップＳ４０６）、ＦＷ更新状態から抜けて通常動作に復帰する（ステップＳ４０７）。また、更新制御装置１０は、ＥＣＵ２０から送信されたＭＡＣ認証失敗応答を車内通信部１２により受信すると、例えば、自動車内部のコンソールによる表示などによりＥＣＵ２０のＦＷ更新に失敗したことを示すメッセージをドライバに提示し（ステップＳ４０８）、処理を終了する。
【００４９】
次に、ＦＷのＭブロック目（ただしＭ＞１）で更新に失敗（ＭＡＣ認証に失敗）した場合の例を図１１のシーケンス図を用いて説明する。図１１のステップＳ５０１からステップＳ５０９までの処理は、１ブロック目を対象ブロックとしたときの図９のステップＳ３０１からステップＳ３０９までの処理と同様である。本例においては、同様の処理がＭ−１ブロック目まで繰り返される。そして、ステップＳ５１０からステップＳ５１４の処理は、Ｍブロック目を対象ブロックとしたときの図９のステップＳ３０１からステップＳ３０５までの処理と同様であるが、ステップＳ５１４における新ＦＷのＭブロック目のブロックデータに対するＭＡＣ認証に失敗したものとする。
【００５０】
新ＦＷのＭブロック目のブロックデータに対するＭＡＣ認証に失敗すると、ＥＣＵ２０は、通信部２１から更新制御装置１０に対してＭＡＣ認証失敗応答を送信する（ステップＳ５１５）。そして、更新制御装置１０とＥＣＵ２０は、すでに新ＦＷのブロックデータの上書きにより更新した１ブロック目からＭ−１ブロック目までを現ＦＷに復元するためのロールバック処理を実施する（ステップＳ５１６）。
【００５１】
次に、図１１のステップＳ５１６において実施されるロールバック処理の詳細について、図１２のシーケンス図に沿って説明する。
【００５２】
まず、更新制御装置１０の制御部１５の制御のもとで、更新制御装置１０の車内通信部１２からＥＣＵ２０に対してロールバック要求が送信される（ステップＳ６０１）。ロールバック要求を受信したＥＣＵ２０は、ロールバック可能応答を更新制御装置１０に送信し（ステップＳ６０２）、ロールバック状態に入る。
【００５３】
ロールバック処理においては、すでに新ＦＷのブロックデータの上書きにより更新した１ブロック目からＭ−１ブロック目まで、図１２のステップＳ６０３からステップＳ６１１までの対象ブロックごとの処理が繰り返される。
【００５４】
すなわち、まず更新制御装置１０の制御部１５が、記憶部１４の更新用ファイル記憶部１４ａに一時記憶された更新用ファイル５０から対象ブロックのパッチデータを読み出すとともに、ＭＡＣ記憶部１４ｂに記憶された対象ブロックの現ＦＷ認証用ＭＡＣを読み出して、車内通信部１２に渡す。そして、車内通信部１２からＥＣＵ２０に対して、対象ブロックのパッチデータと現ＦＷ認証用ＭＡＣが送信される（ステップＳ６０３）。
【００５５】
ＥＣＵ２０は、更新制御装置１０から送信された対象ブロックのパッチデータと現ＦＷ認証用ＭＡＣを通信部２１により受信すると、対象ブロックのパッチデータをパッチ解凍部２２により解凍する（ステップＳ６０４）。そして、パッチ適用部２３が、ＦＷ記憶部２７に記憶されている新ＦＷの対象ブロックのブロックデータを読み出して、このブロックデータに対して解凍した対象ブロックのパッチデータを適用することにより、現ＦＷの対象ブロックのブロックデータを生成し（ステップＳ６０５）、生成したブロックデータをブロックデータ一時記憶部２４に格納する（ステップＳ６０６）。
【００５６】
次に、ＭＡＣ認証部２５が、対象ブロックの現ＦＷ認証用ＭＡＣを用いて、ブロックデータ一時記憶部２４に一時記憶された現ＦＷのブロックデータに対するＭＡＣ認証を行う（ステップＳ６０７）。ここでは、現ＦＷのブロックデータに対するＭＡＣ認証に成功したものとする。なお、現ＦＷのブロックデータに対するＭＡＣ認証に失敗した場合は、ＥＣＵ２０がＦＷの更新も復元もできずに異常状態となるため、例えば、自動車内部のコンソールによる表示などにより、ＥＣＵ２０が異常状態にありディーラーによる対応が必要であることを示すメッセージをドライバに提示することが望ましい。
【００５７】
現ＦＷのブロックデータに対するＭＡＣ認証に成功すると、ＥＣＵ２０の通信部２１から更新制御装置１０に対してＭＡＣ認証成功応答が送信される（ステップＳ６０８）。更新制御装置１０の車内通信部１２は、ＥＣＵ２０から送信されたＭＡＣ認証成功応答を受信すると、制御部１５の制御のもとで、上書き指示をＥＣＵ２０に対して送信する（ステップＳ６０９）。ＥＣＵ２０は、更新制御装置１０から送信された上書き指示を通信部２１により受信すると、ブロックデータ一時記憶部２４に一時記憶されている現ＦＷのブロックデータを上書き部２６により読み出して、ＦＷ記憶部２７に記憶されている新ＦＷの対象ブロックを、ブロックデータ一時記憶部２４から読み出したブロックデータで上書きし、現ＦＷのブロックデータに復元する（ステップＳ６１０）。そして、通信部２１から更新制御装置１０に対して上書き完了応答を送信する（ステップＳ６１１）。
【００５８】
ロールバック処理においては、以上のステップＳ６０４からステップＳ６１１の処理が、復元の対象となる１ブロック目からＭ−１ブロック目まで繰り返される。そして、Ｍ−１ブロック目を対象ブロックとする処理が終了すると、ＥＣＵ２０は、ロールバック状態から抜けて通常動作に復帰する（ステップＳ６１２）。また、更新制御装置１０は、例えば、自動車内部のコンソールによる表示などによりＥＣＵ２０のＦＷ更新に失敗したことを示すメッセージをドライバに提示し（ステップＳ６１３）、処理を終了する。
【００５９】
以上、具体的な例を挙げながら詳細に説明したように、本実施形態によれば、車載ネットワーク１のネットワークバス２に接続されたＥＣＵ２０のＦＷを更新する場合に、更新制御装置１０がＦＷ提供サーバ３０から、更新対象のＥＣＵ２０のＦＷのブロックごとのパッチデータと、このパッチデータを用いて更新された新ＦＷをブロックごとに認証するためのブロックごとの新ＦＷ認証用ＭＡＣとを含む更新用ファイル５０を受信する。そして、更新制御装置１０は、ＥＣＵ２０に対してパッチデータと新ＦＷ認証用ＭＡＣをブロックごとに送信し、ブロックごとの更新結果を受信する。ここで更新制御装置１０は、ＦＷのＭブロック目（ただしＭ＞１）の認証失敗を示す更新結果を受信した場合に、ＦＷ更新時と同じパッチデータを用いてＦＷの１ブロック目からＭ−１ブロック目までを復元するロールバック処理をＥＣＵ２０に対して要求する。したがって、ＥＣＵ２０のＦＷの更新や復元を効率よく行うことができる。
【００６０】
例えば、従来技術では、ＦＷのＭブロック目で更新に失敗し、ロールバック処理によりＦＷの１ブロック目からＭ−１ブロック目までを復元する場合、更新用のパッチデータとは異なる復元用のパッチデータをＦＷ提供サーバ３０から取得してＥＣＵ２０に送信する必要があった。これに対し、本実施形態では、同じパッチデータでＦＷの更新と復元の双方を行うことができるので、ＥＣＵ２０のＦＷの更新や復元を効率よく行うことができる。
【００６１】
＜第２実施形態＞
上述の第１実施形態では、ロールバック処理の際に、更新制御装置１０からＥＣＵ２０に対して復元の対象となる対象ブロックのパッチデータと現ＦＷ認証用ＭＡＣを送信していた。これに対し本実施形態では、ＥＣＵ２０がＦＷ更新時に更新制御装置１０から受信したブロックごとのパッチデータを一時記憶しておくことで、ロールバック処理の際に更新制御装置１０からＥＣＵ２０へのパッチデータの送信を不要としている。また、ＥＣＵ２０が一時記憶したパッチデータを用いてロールバック処理を行うため、更新制御装置１０からＥＣＵ２０への現ＦＷ認証用ＭＡＣの送信も不要となる。以下では、第１実施形態と重複する説明は適宜省略し、第１実施形態と異なる部分についてのみ説明する。
【００６２】
図１３は、本実施形態におけるＥＣＵ２０の機能的な構成例を示すブロック図である。本実施形態におけるＥＣＵ２０は、図６に示した第１実施形態の構成に対し、パッチ一時記憶部２８が追加された構成である。パッチ一時記憶部２８は、更新制御装置１０から送信されて通信部２１が受信したブロックごとのパッチデータ（圧縮されたパッチデータ）を一時的に記憶する。本実施形態では、ロールバック処理の際に復元の対象となる対象ブロックのパッチデータがこのパッチ一時記憶部２８から読み出され、解凍されて新ＦＷのブロックデータに対して適用される。
【００６３】
図１４は、本実施形態のＦＷ更新処理を説明するシーケンス図であり、ＦＷのＭブロック目（ただしＭ＞１）で更新に失敗（ＭＡＣ認証に失敗）した場合の例を示している。この図１４のシーケンス図で示すＦＷ更新処理は、基本的には図１１のシーケンス図で示した第１実施形態の処理と同様であるが、ステップＳ５０１とステップＳ５０２の間、ステップＳ５１０とステップＳ５１１の間に、ＥＣＵ２０が更新制御装置１０から受信したパッチデータをパッチ一時記憶部２８に一時記憶する処理（ステップＳ７０１、ステップＳ７０２）がそれぞれ追加されている。
【００６４】
図１５は、本実施形態のロールバック処理を説明するシーケンス図である。本実施形態では、ロールバック処理の際に、更新制御装置１０からＥＣＵ２０に対してパッチデータや現ＦＷ認証用ＭＡＣは送信されない。ＥＣＵ２０における対象ブロックの現ＦＷへの復元はパッチ一時記憶部２８に一時記憶したパッチデータが用いられる。また、ＥＣＵ２０内部で保持するパッチデータは、すでにＭＡＣ認証を通じて信頼性が確保されたデータであるため、改めて現ＦＷ認証用ＭＡＣを用いて復元した現ＦＷのＭＡＣ認証を行う必要はない。
【００６５】
本実施形態では、まず、更新制御装置１０の制御部１５の制御のもとで、更新制御装置１０の車内通信部１２からＥＣＵ２０に対してロールバック要求が送信される（ステップＳ８０１）。ロールバック要求を受信したＥＣＵ２０は、ロールバック状態に入り、１ブロック目からＭ−１ブロック目まで、図１５のステップＳ８０２からステップＳ８０４までの対象ブロックごとの処理を繰り返す。
【００６６】
すなわち、ＥＣＵ２０は、まず対象ブロックのパッチデータをパッチ一時記憶部２８から読み出して、パッチ解凍部２２により解凍する（ステップＳ８０２）。そして、パッチ適用部２３が、ＦＷ記憶部２７に記憶されている新ＦＷの対象ブロックのブロックデータを読み出して、このブロックデータに対して解凍した対象ブロックのパッチデータを適用することにより、現ＦＷの対象ブロックのブロックデータを生成する（ステップＳ８０３）。そして、上書き部２６が、ＦＷ記憶部２７に記憶されている新ＦＷの対象ブロックを、ステップＳ８０３で生成されたブロックデータで上書きし、現ＦＷのブロックデータに復元する（ステップＳ８０４）。
【００６７】
本実施形態においては、ＥＣＵ２０が、以上のステップＳ８０２からステップＳ８０４の処理を、復元の対象となる１ブロック目からＭ−１ブロック目まで繰り返す。そして、Ｍ−１ブロック目を対象ブロックとする処理が終了すると、ＥＣＵ２０は、通信部２１から更新制御装置１０に対してロールバック完了応答を送信し（ステップＳ８０５）、ロールバック状態から抜けて通常動作に復帰する（ステップＳ８０６）。また、更新制御装置１０は、ＥＣＵ２０から送信されたロールバック完了応答を車内通信部１２により受信すると、例えば、自動車内部のコンソールによる表示などによりＥＣＵ２０のＦＷ更新に失敗したことを示すメッセージをドライバに提示し（ステップＳ８０７）、処理を終了する。
【００６８】
以上のように、本実施形態では、ＥＣＵ２０がＦＷ更新時に更新制御装置１０から受信したブロックごとのパッチデータを一時記憶し、ロールバック処理が必要になった場合には一時記憶したパッチデータを用いてロールバック処理を行うようにしている。したがって、ロールバック処理の際の更新制御装置１０とＥＣＵ２０との間の通信量を削減できるとともに、ＥＣＵ２０におけるＭＡＣ認証処理を不要とすることができ、ＥＣＵ２０のＦＷの更新や復元をさらに効率よく行うことが可能となる。
【００６９】
＜補足説明＞
上述した実施形態の更新制御装置１０は、例えば、一般的なコンピュータシステムのハードウェア構成を利用して実現することができる。図１６は、上述した実施形態の更新制御装置１０のハードウェア構成例を示すブロック図である。更新制御装置１０は、例えば図１６に示すように、ＣＰＵ（Central  Processing  Unit）やＧＰＵ（Graphics  Processing  Unit）などのプロセッサ（プロセッサ回路）１０１と、ＲＡＭ（Random  Access  Memory）やＲＯＭ（Read  Only  Memory）などの内部メモリ１０２と、ＨＤＤ（Hard  Disk  Drive）やＳＤＤ（Solid  State  Drive）などのストレージデバイス１０３と、外部ネットワーク３に接続するための物理インタフェースである通信Ｉ／Ｆ１０４と、車載ネットワーク１のネットワークバス２に接続するための物理インタフェースであるバスＩ／Ｆ１０５とを備える。
【００７０】
そして、例えばプロセッサ１０１が内部メモリ１０２を作業領域として利用しながら、ストレージデバイス１０３や内部メモリ１０２などに格納された所定の制御プログラムを実行することで、上述の署名認証部１３や制御部１５の機能を実現することができる。また、プロセッサ１０１が制御プログラムを実行して通信Ｉ／Ｆ１０４の動作を制御することで、上述の車外通信部１１の機能を実現することができ、プロセッサ１０１が制御プログラムを実行してバスＩ／Ｆ１０５の動作を制御することで、上述の車内通信部１２の機能を実現することができる。また、上述の記憶部１４の機能は、ストレージデバイス１０３を用いて実現することができる。
【００７１】
更新制御装置１０の機能的な構成要素を実現するための制御プログラムは、例えば、磁気ディスク（フレキシブルディスク、ハードディスクなど）、光ディスク（ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ−ＲＯＭ、ＤＶＤ±Ｒ、ＤＶＤ±ＲＷ、Ｂｌｕ−ｒａｙ（登録商標）Ｄｉｓｃなど）、半導体メモリ、またはこれに類する記録媒体に記録されて提供される。なお、プログラムを記録する記録媒体は、コンピュータが読み取り可能な記録媒体であれば、その記憶形式は何れの形態であってもよい。また、上記制御プログラムを、更新制御装置１０のコンピュータシステムに予めインストールするように構成してもよいし、ネットワークを介して配布される上記の制御プログラムをコンピュータシステムに適宜インストールするように構成してもよい。
【００７２】
なお、上述した実施形態の更新制御装置１０は、機能的な構成要素の一部または全部を、ＡＳＩＣ（Application  Specific  Integrated  Circuit）やＦＰＧＡ（Field-Programmable  Gate  Array）などの専用のハードウェアにより実現する構成であってもよい。
【００７３】
また、上述した実施形態の更新制御装置１０は、必ずしも単体の装置として構成されている必要はなく、複数台の装置（コンピュータ）を連携させて実現する構成であってもよい。すなわち、上述した更新制御装置１０の機能的な構成要素を複数台の装置（コンピュータ）に分散して実現する構成であってもよい。また、上述した実施形態の更新制御装置１０は、クラウドシステム上で動作する仮想マシンであってもよい。
【００７４】
以上、本発明の実施形態を説明したが、この実施形態は例として提示したものであり、発明の範囲を限定することは意図していない。この新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【符号の説明】
【００７５】
１  車載ネットワーク
２  ネットワークバス
３  外部ネットワーク
１０  更新制御装置
１１  車外通信部
１２  車内通信部
１３  署名認証部
１４  記憶部  
１５  制御部
２０  ＥＣＵ
３０  ＦＷ提供サーバ
【図１】
2019036238.tif 000003
【図２】
2019036238.tif 000004
【図３】
2019036238.tif 000005
【図４】
2019036238.tif 000006
【図５】
2019036238.tif 000007
【図６】
2019036238.tif 000008
【図７】
2019036238.tif 000009
【図８】
2019036238.tif 000010
【図９】
2019036238.tif 000011
【図１０】
2019036238.tif 000012
【図１１】
2019036238.tif 000013
【図１２】
2019036238.tif 000014
【図１３】
2019036238.tif 000015
【図１４】
2019036238.tif 000016
【図１５】
2019036238.tif 000017
【図１６】
2019036238.tif 000018