(57)【特許請求の範囲】
【請求項１】
車両に搭載された複数の制御装置と、複数の前記制御装置と車内通信可能に接続された中継装置と、前記中継装置と車外通信可能に接続された管理サーバと、を含むプログラム更新システムであって、
前記中継装置は、
複数の前記制御装置に関する制御プログラムの現状のバージョン情報と、自車両の車両識別番号を前記管理サーバに送信し、制御プログラムを前記管理サーバから通知された新バージョンに更新するための複数の更新プログラムを受信する車外通信部と、
受信した複数の前記更新プログラムを記憶する記憶部と、
記憶された複数の前記更新プログラムを対応する前記制御装置にそれぞれ送信する車内通信部と、
前記更新プログラムを受信したすべての前記制御装置が前記更新プログラムを用いた制御プログラムの更新を完了するまで、当該制御装置に制御プログラムの更新を継続させる、更新継続処理を実行する処理部と、を備え、
前記更新継続処理は、
いずれかの前記制御装置において途中で更新が中断した場合に、中断した当該制御装置に中断点から更新を再開させる更新復帰処理であり、
前記更新復帰処理は、
障害からの復帰後に、複数の前記制御装置のうち新バージョンへの書き換えを途中で中断した制御装置がどれかを探索する処理と、
途中で中断した制御装置に中断点からの書き換えの再開を指示する処理と、
途中で中断しなかった制御装置に当初からの書き換えを指示する処理と、を含むプログラム更新システム。
【請求項２】
前記管理サーバは、
前記バージョン情報と前記車両識別番号を前記中継装置から受信する通信部と、
動作確認が取れている前記制御プログラムのバーションの組み合わせごとに識別番号が付与されたテーブルを、前記車両識別番号ごとに記憶する記憶部と、
受信した前記バージョン情報と前記車両識別番号に基づいて、１つの前記識別番号に対応する前記制御プログラムのバーションの組み合わせを、前記車両に搭載された複数の前記制御装置に適用する新バーションとして抽出する処理部と、を備え、
前記通信部は、抽出された前記制御プログラムの新バーションの組み合わせを前記中継装置に通知する請求項１に記載のプログラム更新システム。
【請求項３】
車両に搭載された複数の制御装置と車内通信可能に接続された中継装置が実行するプログラム更新方法であって、
複数の前記制御装置に関する制御プログラムの現状のバージョン情報と、自車両の車両識別番号を管理サーバに送信し、制御プログラムを前記管理サーバから通知された新バージョンに更新するための複数の更新プログラムを受信するステップと、
受信した複数の前記更新プログラムを記憶するステップと、
記憶された複数の前記更新プログラムを対応する前記制御装置にそれぞれ送信するステップと、
前記更新プログラムを受信したすべての前記制御装置が前記更新プログラムを用いた制御プログラムの更新を完了するまで、当該制御装置に制御プログラムの更新を継続させる、更新継続処理を実行するステップと、を含み、
前記更新継続処理は、
いずれかの前記制御装置において途中で更新が中断した場合に、中断した当該制御装置に中断点から更新を再開させる更新復帰処理であり、
前記更新復帰処理は、
障害からの復帰後に、複数の前記制御装置のうち新バージョンへの書き換えを途中で中断した制御装置がどれかを探索する処理と、
途中で中断した制御装置に中断点からの書き換えの再開を指示する処理と、
途中で中断しなかった制御装置に当初からの書き換えを指示する処理と、を含むプログラム更新方法。
【請求項４】
車両に搭載された複数の制御装置と車内通信可能に接続された中継装置として、コンピュータを機能させるためのコンピュータプログラムであって、
複数の前記制御装置に関する制御プログラムの現状のバージョン情報と、自車両の車両識別番号を管理サーバに送信し、制御プログラムを前記管理サーバから通知された新バージョンに更新するための複数の更新プログラムを受信するステップと、
受信した複数の前記更新プログラムを記憶するステップと、
記憶された複数の前記更新プログラムを対応する前記制御装置にそれぞれ送信するステップと、
前記更新プログラムを受信したすべての前記制御装置が前記更新プログラムを用いた制御プログラムの更新を完了するまで、当該制御装置に制御プログラムの更新を継続させる、更新継続処理を実行するステップと、を含み、
前記更新継続処理は、
いずれかの前記制御装置において途中で更新が中断した場合に、中断した当該制御装置に中断点から更新を再開させる更新復帰処理であり、
前記更新復帰処理は、
障害からの復帰後に、複数の前記制御装置のうち新バージョンへの書き換えを途中で中断した制御装置がどれかを探索する処理と、
途中で中断した制御装置に中断点からの書き換えの再開を指示する処理と、
途中で中断しなかった制御装置に当初からの書き換えを指示する処理と、を含むプログラム更新方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、プログラム更新システム、プログラム更新方法及びコンピュータプログラムに関する。具体的には、本発明は、複数の制御装置に対する制御プログラムの同時更新を適切に行うための技術に関する。
【背景技術】
【０００２】
近年、自動車の技術分野においては、車両の高機能化が進行しており、多種多様な車載機器が車両に搭載されている。従って、車両には、各車載機器を制御するための制御装置である、所謂ＥＣＵ（Electronic Control Unit）が多数搭載されている。
ＥＣＵには、例えば、アクセル、ブレーキ、ハンドルの操作に対してエンジンやブレーキ、ＥＰＳ（Electric Power Steering）等の制御を行う走行系に関わるもの、乗員によるスイッチ操作に応じてヘッドライトの点灯／消灯やワイパーＯＮ／ＯＦＦ、ドアロック／アンロック等、運転席近傍に配設されるメータ類の動作を行うものがある。
【０００３】
一般的にＥＣＵは、マイクロコンピュータ等の演算処理装置によって構成されており、ＲＯＭ（Read Only Memory）に記憶した制御プログラムを読み出して実行することにより、車載機器の制御が実現される。
ＥＣＵの制御プログラムは、車両の仕向け地やグレードなど応じて異なることがあり、制御プログラムのバージョンアップに対応して、旧バージョンの制御プログラムを新バージョンの制御プログラムに書き換える必要がある。
【０００４】
例えば、特許文献１及び２には、車載通信機などのゲートウェイが管理サーバから更新プログラムを受信し、受信した更新プログラム用いてＥＣＵが制御プログラムを旧バーションから新バーションに書き換えることにより、車両の各ＥＣＵに対するプログラム更新を無線通信によって遠隔で実行する技術が開示されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００７−６５８５６号公報
【特許文献２】特開２０１０−１９８１５５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
管理サーバから受信した更新プログラムを用いて、ＥＣＵが制御プログラムを更新する最中に、電源失陥やファイル欠損などの何らかの障害が発生することがある。この場合、ＥＣＵが旧バーションへの復元が可能ならば、障害がなくなった後に新バーションの制御プログラムの書き込みを最初からやり直すようにすればよい。
しかし、車両に搭載された複数のＥＣＵの制御プログラムを同時に更新する場合には、１つＥＣＵの書き込み中に障害が生じた時に、他のＥＣＵが既に新バーションへの更新を完了している場合がある。
【０００７】
この場合、障害が生じたＥＣＵが旧バージョンで動作すると、旧バーションで動作するＥＣＵと新バーションで動作するＥＣＵが混在し、新旧バーションの制御プログラムの相性問題などによりＥＣＵが動作不良に陥る可能性がある。
本発明は、かかる従来の問題点に鑑み、複数の制御装置の制御プログラムを同時に更新する場合に、制御装置に動作不良が生じる事態を未然に防止することができる、プログラム更新システム等を提供することを目的とする。
【課題を解決するための手段】
【０００８】
（１）  本発明の一態様に係るシステムは、車両に搭載された複数の制御装置と、複数の前記制御装置と車内通信可能に接続された中継装置と、前記中継装置と車外通信可能に接続された管理サーバと、を含むプログラム更新システムであって、前記中継装置は、複数の前記制御装置に関する制御プログラムの現状のバージョン情報と、自車両の車両識別番号を前記管理サーバに送信し、制御プログラムを前記管理サーバから通知された新バージョンに更新するための複数の更新プログラムを受信する車外通信部と、受信した複数の前記更新プログラムを記憶する記憶部と、記憶された複数の前記更新プログラムを対応する前記制御装置にそれぞれ送信する車内通信部と、前記更新プログラムを受信したすべての前記制御装置が前記更新プログラムを用いた制御プログラムの更新を完了するまで、当該制御装置に制御プログラムの更新を継続させる、更新継続処理を実行する処理部と、を備える。
【０００９】
（５）  本発明の一態様に係る方法は、車両に搭載された複数の制御装置と車内通信可能に接続された中継装置が実行するプログラム更新方法であって、複数の前記制御装置に関する制御プログラムの現状のバージョン情報と、自車両の車両識別番号を前記管理サーバに送信し、制御プログラムを前記管理サーバから通知された新バージョンに更新するための複数の更新プログラムを受信するステップと、受信した複数の前記更新プログラムを記憶するステップと、記憶された複数の前記更新プログラムを対応する前記制御装置にそれぞれ送信するステップと、前記更新プログラムを受信したすべての前記制御装置が前記更新プログラムを用いた制御プログラムの更新を完了するまで、当該制御装置に制御プログラムの更新を継続させる、更新継続処理を実行するステップと、を含む。
【００１０】
（６）  本発明の一態様に係るコンピュータプログラムは、車両に搭載された複数の制御装置と車内通信可能に接続された中継装置として、コンピュータを機能させるためのコンピュータプログラムであって、複数の前記制御装置に関する制御プログラムの現状のバージョン情報と、自車両の車両識別番号を前記管理サーバに送信し、制御プログラムを前記管理サーバから通知された新バージョンに更新するための複数の更新プログラムを受信するステップと、受信した複数の前記更新プログラムを記憶するステップと、記憶された複数の前記更新プログラムを対応する前記制御装置にそれぞれ送信するステップと、前記更新プログラムを受信したすべての前記制御装置が前記更新プログラムを用いた制御プログラムの更新を完了するまで、当該制御装置に制御プログラムの更新を継続させる、更新継続処理を実行するステップと、を含む。
【発明の効果】
【００１１】
本発明によれば、複数の制御装置の制御プログラムを同時に更新する場合に、制御装置に動作不良が生じる事態を未然に防止することができる。
【図面の簡単な説明】
【００１２】
【図１】本発明の実施形態に係るプログラム更新システムの全体構成図である。
【図２】ゲートウェイの内部構成を示すブロック図である。
【図３】ＥＣＵの内部構成を示すブロック図である。
【図４】管理サーバの内部構成を示すブロック図である。
【図５】複数のＥＣＵに対する制御プログラムの同時更新の一例を示すシーケンス図である。
【図６】制御プログラムの動作領域を複数有するＥＣＵが実行する制御プログラムの書き換え処理を示す状態遷移図である。
【図７】複数領域ＥＣＵに対してゲートウェイが実行するロールバック処理の説明図である。
【図８】制御プログラムの動作領域を１つ有するＥＣＵが実行する制御プログラムの書き換え処理を示す状態遷移図である。
【図９】単独領域ＥＣＵに対してゲートウェイが実行する更新復帰処理の一例を示すフローチャートである。
【図１０】更新プログラムを自身で適用できないＥＣＵを含む場合の、制御プログラムの同時更新の一例を示すシーケンス図である。
【発明を実施するための形態】
【００１３】
＜本発明の実施形態の概要＞  
以下、本発明の実施形態の概要を列記して説明する。
（１）  本実施形態のプログラム更新システムは、車両に搭載された複数の制御装置と、複数の前記制御装置と車内通信可能に接続された中継装置と、前記中継装置と車外通信可能に接続された管理サーバと、を含むプログラム更新システムであって、前記中継装置は、複数の前記制御装置に関する制御プログラムの現状のバージョン情報と、自車両の車両識別番号を前記管理サーバに送信し、制御プログラムを前記管理サーバから通知された新バージョンに更新するための複数の更新プログラムを受信する車外通信部と、受信した複数の前記更新プログラムを記憶する記憶部と、記憶された複数の前記更新プログラムを対応する前記制御装置にそれぞれ送信する車内通信部と、前記更新プログラムを受信したすべての前記制御装置が前記更新プログラムを用いた制御プログラムの更新を完了するまで、当該制御装置に制御プログラムの更新を継続させる、更新継続処理を実行する処理部と、を備える。
【００１４】
本実施形態のプログラム更新システムによれば、中継装置の処理部が、更新プログラムを受信したすべての制御装置が更新プログラムを用いた制御プログラムの更新を完了するまで、当該制御装置に制御プログラムの更新を継続させる、更新継続処理を実行するので、旧バーションで動作する制御装置と新バーションで動作する制御装置が混在しない。
このため、複数の制御装置の制御プログラムを同時に更新する場合に、制御装置に動作不良が生じる事態を未然に防止することができる。
【００１５】
（２）  本実施形態のプログラム更新システムにおいて、複数の前記制御装置が、前記制御プログラムの動作領域が複数存在する記憶装置を有する複数領域タイプである場合には、前記更新継続処理として、いずれかの前記制御装置において途中で更新が中断した場合に、中断した当該制御装置に中断点から更新を再開させる更新復帰処理を採用すればよい。また、旧バージョンを他領域にバックアップとして確保しているため、リプロ対象のＥＣＵを一斉に復帰させる（「ロールバック」という）こともできる。
【００１６】
本実施形態のプログラム更新システムではこの場合、基本的に中断点から再開させるが、場合によっては、すぐに車両を動かす必要がある事態が生じる。中継装置の処理部が上記のロールバック処理を実行すると、短時間で復帰できる。いずれも旧バーションで動作する制御装置と新バーションで動作する制御装置が混在しない。
このため、複数の制御装置の制御プログラムを同時に更新する場合に、制御装置に動作不良が生じる事態を未然に防止することができる。
【００１７】
（３）  本実施形態のプログラム更新システムにおいて、複数の前記制御装置が、前記制御プログラムの動作領域が１つ存在する記憶装置を有する単独領域タイプである場合には、前記更新継続処理として、いずれかの前記制御装置において途中で更新が中断した場合に、中断した当該制御装置に中断点から更新を再開させる更新復帰処理を採用すればよい。
【００１８】
この場合、中継装置の処理部が上記の更新復帰処理を実行すると、更新を中断した制御装置が中断点から更新を再開するので、旧バーションで動作する制御装置と新バーションで動作する制御装置が混在しない。
このため、複数の制御装置の制御プログラムを同時に更新する場合に、制御装置に動作不良が生じる事態を未然に防止することができる。
【００１９】
（４）  本実施形態のプログラム更新システムにおいて、前記管理サーバは、前記バージョン情報と前記車両識別番号を前記中継装置から受信する通信部と、動作確認が取れている前記制御プログラムのバーションの組み合わせごとに識別番号が付与されたテーブル（例えば、図４のリビジョンテーブルＲＴ）を、前記車両識別番号ごとに記憶する記憶部と、受信した前記バージョン情報と前記車両識別番号に基づいて、１つの前記識別番号に対応する前記制御プログラムのバーションの組み合わせを、前記車両に搭載された複数の前記制御装置に適用する新バーションとして抽出する処理部と、を備え、前記通信部は、抽出された前記制御プログラムの新バーションの組み合わせを前記中継装置に通知することが好ましい。
【００２０】
本実施形態のプログラム更新システムによれば、管理サーバの処理部が、受信したバージョン情報と車両識別番号に基づいて、１つの識別番号（リビジョン番号）に対応する制御プログラムのバーションの組み合わせを、車両に搭載された複数の制御装置に適用する新バーションとして抽出し、管理サーバの通信部が、抽出された制御プログラムの新バーションの組み合わせを中継装置に通知する。
このため、管理サーバから通知された新バーションの組み合わせ通りに複数の制御装置が更新を実行すれば、複数の制御装置について相性問題などに伴う動作不良が発生するのを未然に防止することができる。
【００２１】
（５）  本実施形態のプログラム更新方法は、上述の（１）〜（４）のいずれかに記載のプログラム更新システムに含まれる中継装置が実行するプログラム更新方法に関する。
従って、本実施形態のプログラム更新方法は、上述の（１）〜（４）のいずれかに記載のプログラム更新システムと同様の作用効果を奏する。
【００２２】
（６）  本実施形態のコンピュータプログラムは、上述の（１）〜（４）のいずれかに記載のプログラム更新システムに含まれる中継装置として、コンピュータを機能させるためのコンピュータプログラムに関する。
従って、本実施形態のコンピュータプログラムは、上述の（１）〜（４）のいずれかに記載のプログラム更新システムと同様の作用効果を奏する。
【００２３】
＜本発明の実施形態の詳細＞  
以下、図面を参照して、本発明の実施形態の詳細を説明する。なお、以下に記載する実施形態の少なくとも一部を任意に組み合わせてもよい。
【００２４】
〔システムの全体構成〕
図１は、本発明の実施形態に係るプログラム更新システムの全体構成図である。
図１に示すように、本実施形態のプログラム更新システムは、広域通信網２を介して通信可能な車両１、管理サーバ５及びＤＬ（ダウンロード）サーバ６を含む。
管理サーバ５及びＤＬサーバ６は、例えば、車両１のカーメーカーにより運営されており、予め会員登録されたユーザが所有する多数の車両１と通信可能である。
【００２５】
車両１には、ゲートウェイ１０及び複数のＥＣＵ３０と、各ＥＣＵ３０によりそれぞれ制御される各種の車載機器（図示せず）が搭載されている。
車両１には、共通の車内通信線にバス接続された複数のＥＣＵ３０による通信グループが存在し、ゲートウェイ１０は、通信グループ間の通信を中継している。このため、ゲートウェイ１０には、複数の車内通信線が接続されている。
【００２６】
ゲートウェイ１０は、携帯電話網などの広域通信網２に通信可能に接続されている。ゲートウェイ１０は、広域通信網２を通じて管理サーバ５及びＤＬサーバ６などの車外装置から受信した情報をＥＣＵ３０に送信する。
ゲートウェイ１０は、ＥＣＵ３０から取得した情報を、広域通信網２を介して管理サーバ５などの車外装置に送信する。
【００２７】
図１では、ゲートウェイ１０が車外装置と直接通信を行う場合が例示されている。もっとも、ゲートウェイ１０に別の通信装置を接続し、別の通信装置を介して車外装置と通信を行う構成としてもよい。
ゲートウェイ１０に接続される別の通信装置としては、例えば、ユーザが所有する携帯電話機、スマートフォン、タブレット型端末、ノートＰＣ（Personal Computer）等の装置が考えられる。
【００２８】
図１のプログラム更新システムでは、管理サーバ５とＤＬサーバ６が別個のサーバで構成されているが、これらのサーバ５，６を１つのサーバ装置で構成してもよい。
【００２９】
〔ゲートウェイの内部構成〕
図２はゲートウェイ１０の内部構成を示すブロック図である。
図２に示すように、ゲートウェイ１０は、ＣＰＵ（Central Processing Unit）１１、ＲＡＭ（Random Access Memory）１２、記憶部１３、及び車内通信部１４などを備える。ゲートウェイ１０は、無線通信部１５と車内通信線を介して接続されているが、これらは一つの装置で構成してもよい。
【００３０】
ＣＰＵ１１は、記憶部１３に記憶された一又は複数のプログラムをＲＡＭ１２に読み出して実行することにより、ゲートウェイ１０を各種情報の中継装置として機能させる。
ＣＰＵ１１は、例えば時分割で複数のプログラムを切り替えて実行することにより、複数のプログラムを並列的に実行可能である。ＲＡＭ１２は、ＳＲＡＭ（Static ＲＡＭ）又はＤＲＡＭ（Dynamic ＲＡＭ）等のメモリ素子で構成され、ＣＰＵ１１が実行するプログラム及び実行に必要なデータ等が一時的に記憶される。
【００３１】
記憶部１３は、フラッシュメモリ若しくはＥＥＰＲＯＭ（Electrically Erasable Programmable Read Only Memory）等の不揮発性のメモリ素子などにより構成されている。
記憶部１３は、ＣＰＵ１１が実行するプログラム及び実行に必要なデータ等を記憶する記憶領域を有する。記憶部１３は、ＤＬサーバ６から受信した各ＥＣＵ３０の更新プログラムなども記憶する。
【００３２】
車内通信部１４には、車両１に配設された車内通信線を介して複数のＥＣＵ３０が接続されている。車内通信部１４は、例えばＣＡＮ（Controller Area Network）、ＣＡＮＦＤ（ＣＡＮ with Flexible Data Rate）、ＬＩＮ（Local Interconnect Network）、Ｅｔｈｅｒｎｅｔ（登録商標）、又はＭＯＳＴ（Media Oriented Systems Transport：ＭＯＳＴは登録商標）等の規格に応じて、ＥＣＵ３０との通信を行う。
車内通信部１４は、ＣＰＵ１１から与えられた情報を対象のＥＣＵ３０へ送信するとともに、ＥＣＵ３０から受信した情報をＣＰＵ１１に与える。車内通信部１４は、上記通信規格だけでなく、車載ネットワークに用いる他の通信規格によって通信してもよい。
【００３３】
無線通信部１５は、アンテナと、アンテナからの無線信号の送受信を実行する通信回路とを含む無線通信機よりなる。無線通信部１５は、携帯電話網等の広域通信網２に接続されることにより車外装置との通信が可能である。
無線通信部１５は、図示しない基地局により形成される広域通信網２を介して、ＣＰＵ１１から与えられた情報を管理サーバ５等の車外装置に送信するとともに、車外装置から受信した情報をＣＰＵ１１に与える。
【００３４】
ゲートウェイ１０において、無線通信部１５に代えて、上述の別の通信装置が接続される有線通信部を採用してもよい。この有線通信部は、ＵＳＢ（Universal Serial Bus）又はＲＳ２３２Ｃ等の規格に応じた通信ケーブルを介して通信装置を接続するコネクタを有し、通信ケーブルを介して接続された別の通信装置と通信を行う。
有線通信部は、ＣＰＵ１１から与えられた情報を別の通信装置により車外装置へ送信するとともに、広域通信網２を通じて車外装置から受信した情報をＣＰＵ１１に与える。
【００３５】
〔ＥＣＵの内部構成〕
図３はＥＣＵ３０の内部構成を示すブロック図である。
図３に示すように、ＥＣＵ３０は、ＣＰＵ３１、ＲＡＭ３２、記憶部３３、通信部３４などを備える。ＥＣＵ３０は、車両１に搭載された複数の車載機器を個別に制御する制御装置である。ＥＣＵ３０の種類には、例えば、エンジン制御ＥＣＵ、ステアリング制御ＥＣＵ、及びドアロック制御ＥＣＵなどがある。
【００３６】
ＣＰＵ３１は、記憶部３３に予め記憶された一又は複数のプログラムをＲＡＭ３２に読み出して実行することにより、自身が担当する車載機器の動作を制御する。
ＲＡＭ３２は、ＳＲＡＭ又はＤＲＡＭ等のメモリ素子で構成され、ＣＰＵ３１が実行するプログラム及び実行に必要なデータ等が一時的に記憶される。
【００３７】
記憶部３３は、フラッシュメモリ若しくはＥＥＰＲＯＭ等の不揮発性のメモリ素子、或いは、ハードディスクなどの磁気記憶装置等により構成されている。
記憶部３３が記憶する情報には、例えば、制御対象である車載装置を制御するための処理をＣＰＵ３１に実行させるためのコンピュータプログラム（以下、「制御プログラム」という。）が含まれる。
【００３８】
通信部３４には、車両１に配設された車内通信線を介してゲートウェイ１０が接続されている。通信部３４は、例えばＣＡＮ、Ｅｔｈｅｒｎｅｔ、又はＭＯＳＴ等の規格に応じて、ゲートウェイ１０との通信を行う。
通信部３４は、ＣＰＵ３１から与えられた情報をゲートウェイ１０へ送信するとともに、ゲートウェイ１０から受信した情報をＣＰＵ３１に与える。通信部３４は、上記通信規格だけなく、車載ネットワークに用いる他の通信規格によって通信してもよい。
【００３９】
ＥＣＵ３０のＣＰＵ３１には、当該ＣＰＵ３１による制御モードを、「通常モード」又は「リプログラミングモード」（以下、「リプロモード」ともいう。）のいずれかに切り替える起動部３５が含まれる。
通常モードとは、ＥＣＵ３０のＣＰＵ３１が本来の制御内容（例えば、エンジン制御やステアリング制御など）を実行する制御モードのことである。リプログラミングモードとは、ＣＰＵ３１が制御プログラムのＲＯＭ領域に対して消去、書き換えの権限が付与されるモードのことである。本モードのときにのみ、制御プログラムを新バージョンに更新することが可能となる。
【００４０】
起動部３５は、リプログラミングモードにおいて新バーションの制御プログラムを記憶部３３に書き込むと、いったん再起動（リセット）して新バージョンの制御プログラムが書き込まれた記憶領域についてベリファイ処理を実行し、ベリファイ処理の完了後にＣＰＵ３１を更新後の制御プログラムによって動作させる。
【００４１】
〔管理サーバの内部構成〕
図４は、管理サーバ５の内部構成を示すブロック図である。
図４に示すように、管理サーバ５は、ＣＰＵ５１、ＲＯＭ５２、ＲＡＭ５３、記憶部５４、及び通信部５５などを備える。
【００４２】
ＣＰＵ５１は、ＲＯＭ５２に予め記憶された一又は複数のプログラムをＲＡＭ５３に読み出して実行することにより、各ハードウェアの動作を制御し、管理サーバ５をゲートウェイ１０と通信可能な車外装置として機能させる。
ＲＡＭ５３は、ＳＲＡＭ又はＤＲＡＭ等のメモリ素子で構成され、ＣＰＵ５１が実行するプログラム及び実行に必要なデータ等が一時的に記憶される。
【００４３】
記憶部５４は、フラッシュメモリ若しくはＥＥＰＲＯＭ等の不揮発性のメモリ素子、又は、ハードディスクなどの磁気記憶装置等により構成されている。
通信部５５は、所定の通信規格に則って通信処理を実行する通信装置よりなり、携帯電話網等の広域通信網２に接続されて当該通信処理を実行する。通信部５５は、ＣＰＵ５１から与えられた情報を、広域通信網２を介して外部装置に送信するとともに、広域通信網２を介して受信した情報をＣＰＵ５１に与える。
【００４４】
図４に示すように、記憶部５４が記憶する情報には、車両１に搭載されたＥＣＵ３０（ここでは、ＶＩＮ＝１の車両１に搭載されたＥＣＵ３０の識別番号を１〜３とする。）の制御プログラムのバーションを記録したリビジョンテーブルＲＴが含まれる。
リビジョンテーブルＲＴは、車両１の車両識別番号（ＶＩＮ）と、車両識別番号ごとのリビジョンアップの履歴を表す識別情報であるリビジョン番号と、各リビジョン番号に対応するＥＣＵ１〜３のバージョンとを纏めたテーブルよりなる。
【００４５】
図４のリビジョンテーブルＲＴにおいて、同じリビジョン番号に含まれる各ＥＣＵ１〜３の制御プログラムのバーションは、カーメーカーにおいて動作確認が取れていることを示している。
例えば、現状のリビジョン番号である「Ｒ２．０」の場合には、ＥＣＵ１のバーション１．０の制御プログラム、ＥＣＵ２のバージョン１．３の制御プログラム、及びＥＣＵ３のバーション２．０の制御プログラムの動作確認が取れている。
【００４６】
最新のリビジョン番号である「Ｒ２．４」の場合には、ＥＣＵ１のバーション１．２の制御プログラム、ＥＣＵ２のバージョン２．０の制御プログラム、及びＥＣＵ３のバーション２．２の制御プログラムの動作確認が取れている。
従って、車両１をＲ２．０からＲ２．４にリビジョンアップする場合には、ＥＣＵ１の１．０から１．２へのバーションアップ、ＥＣＵ２の１．３から２．０へのバーションアップ、及びＥＣＵ３の２．０から２．２へのバーションアップを同時に行う必要がある。
【００４７】
図４のリビジョンテーブルＲＴには、一例として車両識別番号ＶＩＮ＝１の場合のバージョン情報のみが例示されている。
もっとも、管理サーバ５が保持するリビジョンテーブルＲＴには、管理サーバ５の登録会員が所有するすべての車両１の車両識別番号（ＶＩＮ）ごとに、上記と同様のバーション情報が記録されている。また、ＤＬサーバ６には、すべてのＥＣＵ３０に関する複数の更新プログラムが格納されている。
【００４８】
ＣＰＵ５１は、ゲートウェイ１０から車両識別番号と各ＥＣＵ１〜３の現状の制御プログラムのバーションが通知されると、通知されたバーション情報をリビジョンテーブルＲＴに含まれる当該車両識別番号の最新バーションと照合する。
ＣＰＵ５１は、照合の結果、ゲートウェイ１０から通知されたＥＣＵ１〜３のバーション情報が最新でないと判定した場合には、最新バーションに更新するための更新プログラムの保存先ＵＲＬとダウンロード要求をゲートウェイ１０に送信する。
【００４９】
〔制御プログラムの同時更新のシーケンス〕
図５は、本実施形態のプログラム更新システムにおいて実行される、複数のＥＣＵ１〜３に対する制御プログラムの同時更新の一例を示すシーケンス図である。なお、以下においては、図４のリビジョンテーブルＲＴに従って、各ＥＣＵ１〜３の制御プログラムを次のように更新する場合を想定する。
リビジョン番号：Ｒ２．０→Ｒ２．４
ＥＣＵ１：バーション１．０→バーション１．２
ＥＣＵ２：バーション１．３→バーション２．０
ＥＣＵ３：バーション２．０→バーション２．２
【００５０】
更新プログラムは、新バーションのプログラムそのものであってもよいが、本実施形態では、旧バーションからの差分プログラムである場合を想定する。この場合、旧バージョンと新バージョンとのファイルの差分情報を含むΔが同じ記憶領域にあれば、旧バージョンにΔを適応することで、新バージョンに更新することができる。
ＥＣＵ１のバーション１．０からバーション１．２への更新プログラムを「Δ１」とし、ＥＣＵ２のバーション１．３からバーション２．０への更新プログラムを「Δ２」とし、ＥＣＵ３のバーション２．０からバーション２．２への更新プログラムを「Δ３」とする。
【００５１】
図５に示すように、本実施形態の制御プログラムの同時更新においては、まず、ゲートウェイ１０が、各ＥＣＵ１〜３の制御プログラムの現状のバージョン情報を収集する（ステップＳ１）。
図示の例では、ＥＣＵ１の制御プログラムの現バーションは「１．０」であり、ＥＣＵ２の制御プログラムの現バーションは「１．３」であり、ＥＣＵ３の制御プログラムの現バーションは「２．０」である。
【００５２】
次に、ゲートウェイ１０は、収集したＥＣＵ１〜３の制御プログラムのバージョン情報と、自車両の車両識別番号（ＶＩＮ）を管理サーバ５に送信する（ステップＳ２）。
管理サーバ５は、ゲートウェイ１０から通知されたバージョン情報と車両識別番号に基づいて、前述のリビジョンテーブルＲＴ（図４参照）を探索することにより、各ＥＣＵ１〜３について、車両１の各ＥＣＵ１〜３の制御プログラムを同時に更新する必要があるか否かを判定する。
【００５３】
ここでは、ＥＣＵ１がバーション１．０であり、ＥＣＵ２がバーション１．３であり、ＥＣＵ３がバーション２．０であるから、管理サーバ５は、車両１がリビジョンＲ２．０で運用中であると判定する。
また、管理サーバ５は、最新版のリビジョンＲ２．４が存在することから、ＥＣＵ１のバーション１．２への更新、ＥＣＵ２のバーション２．０への更新、及び、ＥＣＵ３のバーション２．２への更新を、同時に行う必要があると判定する。
【００５４】
そこで、管理サーバ５は、バーション情報を送信してきたゲートウェイ１０宛てに、各ＥＣＵ１〜３の更新プログラムΔ１〜Δ３の保存先ＵＲＬとダウンロード要求をゲートウェイ１０宛てに送信する（ステップＳ３）。
これにより、ゲートウェイ１０は、各ＥＣＵ１〜３のための更新プログラムΔ１〜Δ３をＤＬサーバ６からダウンロードする（ステップＳ４）。ゲートウェイ１０は、受信した更新プログラムΔ１〜Δ３を自装置の記憶部１３に一時的に格納して保存する。
【００５５】
更新プログラムΔ１〜Δ３の保存が完了すると、ゲートウェイ１０は、ＤＬが正常に完了したことを管理サーバ５に送信する（ステップＳ５）。引き続き自動で更新を行う場合、ＤＬ完了通知を受信した管理サーバ５は、制御プログラムの更新要求をゲートウェイ１０に送信する。ＤＬ完了後、一時中断し外部から更新要求を受けてから、制御プログラムの更新要求をゲートウェイ１０に送信してもよい（ステップＳ６）。
更新要求を受信したゲートウェイ１０は、記憶部１３に保存した更新プログラムΔ１〜Δ３を用いて制御プログラムを更新させるべく、各ＥＣＵ１〜３にリプロモード移行要求をそれぞれ送信する（ステップＳ７）。
【００５６】
リプロモード移行要求を受信すると、各ＥＣＵ１〜３は自身の制御モードを通常モードからリプログラミングモードに切り替える。これにより、各ＥＣＵ１〜３は、更新プログラムΔ１〜Δ３の展開と、現状の制御プログラムを新バーションの制御プログラムに書き換える処理が可能な状態となる。
【００５７】
ゲートウェイ１０は、記憶部１３に保存した更新プログラムΔ１をＥＣＵ１に送信する（ステップＳ８）。
ＥＣＵ１は、受信した更新プログラムΔ１を展開して旧バーション１．０に適用することにより、制御プログラムを旧バーション１．０から新バーション１．２に書き換える。書き換えが完了すると、ＥＣＵ１は、書き換えの完了通知をゲートウェイ１０に送信する（ステップＳ９）。
【００５８】
ゲートウェイ１０は、記憶部１３に保存した更新プログラムΔ２をＥＣＵ２に送信する（ステップＳ１０）。
ＥＣＵ２は、受信した更新プログラムΔ２を展開して旧バーション１．３に適用することにより、制御プログラムを旧バーション１．３から新バーション２．０に書き換える。書き換えが完了すると、ＥＣＵ２は、書き換えの完了通知をゲートウェイ１０に送信する（ステップＳ１１）。
【００５９】
ゲートウェイ１０は、記憶部１３に保存した更新プログラムΔ３をＥＣＵ３に送信する（ステップＳ１２）。
ＥＣＵ３は、受信した更新プログラムΔ３を展開して旧バーション２．０に適用することにより、制御プログラムを旧バーション２．０から新バーション２．２に書き換える。書き換えが完了すると、ＥＣＵ３は、書き換えの完了通知をゲートウェイ１０に送信する（ステップＳ１３）。
【００６０】
なお、図５に例示するシーケンスでは、ステップＳ８〜ステップＳ１３までの処理が時系列に表現されているが、これらの処理は同時並行的に行われるので、前後の順番が入れ替わってもよい。
【００６１】
ゲートウェイ１０は、すべてのＥＣＵ１〜３から書き換えの完了通知を受信すると、各ＥＣＵ１〜３に通常モード移行要求とリセット要求を各ＥＣＵ１〜３に送信する（ステップＳ１４）。
通常モード移行要求を受信した各ＥＣＵ１〜３は、自身の制御モードをリプロモードから通常モードに切り替え、リセット要求に応じてシステムを再起動する。これにより、各ＥＣＵ１〜３が、新バーションの制御プログラムによりそれぞれ動作する。
【００６２】
また、ゲートウェイ１０は、書き換えの完了通知をすべてのＥＣＵ１〜３から受信すると、更新完了通知を管理サーバ５に送信する（ステップＳ１５）。
これにより、管理サーバ５は、車両１の各ＥＣＵ１〜３について、制御プログラムの更新がすべて完了したことを察知する。
【００６３】
〔複数領域ＥＣＵによる書き換え処理〕
図６は、制御プログラムの動作領域を複数（図例では２つ）有するＥＣＵ３０（以下、「複数領域ＥＣＵ」という。）が実行する制御プログラムの書き換え処理を示す状態遷移図である。
図６では、ＥＣＵ３０の制御プログラムのバーションを「１．０」から「１．２」に更新する場合を例示しているが、その他のバージョン番号の場合も以下と同様の書き換え処理が実行される。
【００６４】
ＥＣＵ３０の記憶部３３は、制御プログラムが動作可能な２つ主領域１，２と、更新プログラムΔ１が格納される１つのワークスペースとに区分されている。
ＥＣＵ３０の起動部３５は、起動時において制御プログラムの動作領域を主領域１，２のいずれかに選択可能である。ここでは、プログラム更新前の通常モードにおいて、動作領域として主領域１が選択されているものとする。なお、図６中のハッチング付きの領域は制御プログラムが実行されるアクティブな領域を示す。
【００６５】
起動部３５は、リプログラミングモードにおいてゲートウェイ１０から更新プログラムΔ１を受信すると、更新プログラムΔ１をワークスペースに格納するとともに、主領域２に旧バーション１．０の制御プログラムのバックアップを作成する（図６（ａ））。
次に、起動部３５は、更新プログラムΔ１を展開して主領域２のバーション１．０のバックアップに適用し（図６（ｂ））、主領域２の制御プログラムをバーション１．０からバーション１．２に書き換える（図６（ｃ））。
【００６６】
上記の書き換えが完了すると、起動部３５は、動作領域を主領域２に切り替えて主領域２のベリファイ処理を実行したあと（図６（ｄ））、主領域２に格納されたバーション１．２の制御プログラムにてＣＰＵ３１を動作させる（図６（ｅ））。
上記のようにして主領域２に対する制御プログラムの書き換えが完了すると、起動部３５は、通常モードにおける起動時の動作領域を主領域２に切り替えるとともに、書き換えの完了通知をゲートウェイ１０に送信する。
【００６７】
〔複数領域ＥＣＵに対するロールバック処理〕
図７は、複数領域ＥＣＵ３０に対してゲートウェイ１０が実行するロールバック処理の説明図である。
図７において縦横に配列された各ボックスは、各ＥＣＵ１〜３の記憶部３３内の時間経過ごとのメモリ状態Ｒ１〜Ｒ５の変遷を示す。各ボックスの上段部分は図６の「主領域１」に対応し、下段部分は図６の「主領域２」に対応している。
【００６８】
図７において、時間ｔは下向きに進行する。時刻ｔ０は、ゲートウェイ１０によるリプロモード移行要求Ｓ７の送信時点である。
時刻ｔ９は、ゲートウェイ１０による完了通知Ｓ９の受信時点であり、時刻ｔ１１は、ゲートウェイ１０による完了通知Ｓ１１の受信時点であり、時刻ｔ１３は、ゲートウェイ１０による完了通知Ｓ１３の受信時点である。
【００６９】
メモリ状態Ｒ１は、各ＥＣＵ１〜３がリプロモード移行要求Ｓ７を受信したあと、主領域２に旧バーションのバックアップが作成された状態を示している。
メモリ状態Ｒ１では、各ＥＣＵ１〜３が書き換え処理を未だ実行していないので、主領域１，２の双方ともに旧バーションの制御プログラムが格納されている。
メモリ状態Ｒ２は、各ＥＣＵ１〜３が主領域２について書き換え処理を実行中である状態を示している。
【００７０】
メモリ状態Ｒ３は、ＥＣＵ１が主領域２の書き換えを完了して完了通知Ｓ９を送信し、ＥＣＵ２，３が未だ書き換え処理を実行中である状態を示している。
メモリ状態Ｒ４は、更にＥＣＵ２が主領域２の書き換えを完了して完了通知Ｓ１１を送信し、ＥＣＵ３が未だ書き換え処理を実行中である状態を示している。
メモリ状態Ｒ５は、更にＥＣＵ３が主領域２の書き換えを完了して完了通知Ｓ１３を送信し、すべてのＥＣＵ１〜３が新バーションに書き換えられた状態を示している。
【００７１】
ここで、例えばｔ９≦ｔ＜ｔ１１の期間中に、車両１の電源失陥などの何らかの障害により、ＥＣＵ３の書き換え処理が中断時点ｔｐにおいて中断したと仮定する。
この場合、ゲートウェイ１０は、上記の障害がなくなったあとに、リプロモード移行要求Ｓ７をすべてのＥＣＵ１〜３に再送信する。これがロールバック処理である。これにより、書き換え中であったＥＣＵ２，３だけでなく、書き換え済みであったＥＣＵ１についても、当初のメモリ状態Ｒ１から新バーションへの書き換え処理を再度実行する。
【００７２】
なお、ｔ９≦ｔ＜ｔ１１の期間中だけでなく、ｔ０≦ｔ＜ｔ９或いはｔ１１≦ｔ＜ｔ１３の期間中に、電源失陥などの障害に伴う中断時点ｔｐを検出した場合でも、ゲートウェイ１０は同様のロールバック処理を実行する。
すなわち、ゲートウェイ１０は、リプロモード移行要求Ｓ７の送信時点ｔ０から、すべての完了通知Ｓ９，Ｓ１１，Ｓ１３の受信を検出するまでの間は、制御プログラムの書き込みを阻害する障害を検出した場合にロールバック処理を実行する。
【００７３】
このように、本実施形態のプログラム更新システムでは、いずれかのＥＣＵ１〜３において途中で更新が中断した場合に、すべてのＥＣＵ１〜３に更新をやり直させるロールバック処理を実行する。
従って、複数領域ＥＣＵ１〜３の同時更新中においていずれかのＥＣＵ１〜３における書き換え処理が中断した場合に、すべてのＥＣＵ１〜３を動作保障されている現状の旧バージョンに戻すことができる。
【００７４】
このため、旧バーションの制御プログラムで動作するＥＣＵ３０と新バーションの制御プログラムで動作するＥＣＵ３０とが混在することにより、動作保障されていない制御プログラムが同時に動作して動作不良となるのを未然に防止することができる。
なお、上記のロールバック処理は、同時更新の必要性があるすべてのＥＣＵ１〜３が更新プログラムΔ１〜Δ３を用いた制御プログラムの更新を完了するまで、当該ＥＣＵ１〜３に制御プログラムの更新を継続させる「更新継続処理」の一種である。
【００７５】
〔単独領域ＥＣＵによる書き換え処理〕
図８は、制御プログラムの動作領域を１つ有するＥＣＵ３０（以下、「単独領域ＥＣＵ」という。）が実行する制御プログラムの書き換え処理を示す状態遷移図である。
図８では、ＥＣＵ３０の制御プログラムのバーションを「１．０」から「１．２」に更新する場合を例示しているが、その他のバージョン番号の場合も以下と同様の書き換え処理が実行される。
【００７６】
ＥＣＵ３０の記憶部３３は、制御プログラムが動作可能な１つ主領域１と、更新プログラムΔ１が格納される１つのワークスペースとに区分されている。
起動部３５は、リプロモードにおいてゲートウェイ１０から更新プログラムΔ１を受信すると、更新フラグをＯＮに切り替えて、更新プログラムΔ１をワークスペースに格納する（図８（ａ））。
【００７７】
次に、起動部３５は、更新プログラムΔ１を展開して主領域１のバーション１．０のバックアッププログラムに適用し、主領域１の制御プログラムをバーション１．０からバーション１．２に書き換える（図６（ｂ））。
ワークスペースには、書き込み状況の記録部が設けられている。起動部３５は、バーション１．０の制御プログラムのデータを書き換えるごとに、書き込みみ先のブロックアドレスとデータのチェックサム値などを記録部に記載する。
【００７８】
上記の書き換えが完了すると、起動部３５は、更新フラグをＯＦＦにするとともに、書き換えられた主領域１のベリファイ処理を実行し（図６（ｃ））、主領域１に格納されたバーション１．２の制御プログラムにてＣＰＵ３１を動作させる（図６（ｄ））。
上記のようにして主領域１に対する制御プログラムの書き換えが完了すると、起動部３５は、書き換えの完了通知をゲートウェイ１０に送信する。
【００７９】
ここで、主領域１の制御プログラムをバーション１．０からバーション１．２に書き換え中である場合（図６（ｂ）の場合）に、ＥＣＵ３０が電源失陥などにより停止した場合を想定する。
この場合、起動部３５は、電源回復によって再起動すると、記録部のデータ内容に基づいて主領域１に対する書き込みの中断点Ｐを検出し、検出した中断点Ｐから主領域１に対する制御プログラムの書き換えを再開することができる（図６（ｅ））。
【００８０】
〔単独領域ＥＣＵに対する更新復帰処理〕
図８の単独領域ＥＣＵ３０の場合には、いったん新バーションへの書き換え処理が実行されると、旧バーションの制御プログラムでは動作することができない。従って、単独領域ＥＣＵ３０の場合には、前述のロールバック処理（図７）を採用できない。
そこで、車両１のＥＣＵが単独領域ＥＣＵ３０である場合には、ゲートウェイ１０は、いずれかのＥＣＵ１〜３において途中で更新が中断した場合に、中断した当該ＥＣＵ１〜３の中断点Ｐから更新を再開させる「更新復帰処理」を実行する。
【００８１】
図９は、単独領域ＥＣＵ３０に対してゲートウェイ１０が実行する更新復帰処理の一例を示すフローチャートである。
図９の更新復帰処理は、複数の単独領域ＥＣＵ１〜３の同時更新中に電源失陥などの障害が発生したあと、障害から復帰した場合にゲートウェイ１０により実行される。
【００８２】
図９に示すように、ゲートウェイ１０は、まず、リプログラミングモードのＥＣＵ１〜３が存在する否かを判定する（ステップＳＴ１）。
ステップＳＴ１の判定結果が否定的である場合は、ゲートウェイ１０は、管理サーバ５に更新完了通知を送信する（ステップＳＴ５）。
ステップＳＴ１の判定結果が肯定的である場合は、ゲートウェイ１０は、ＥＣＵ１〜３ごとに更新完了通知があったか否かを判定する（ステップＳＴ２）。
【００８３】
ステップＳＴ２の判定結果が否定的である場合は、ゲートウェイ１０は、障害発生による中断点Ｐが存在するか否かを判定する（ステップＳＴ６）。
ステップＳＴ２の判定結果が肯定的である場合は、ゲートウェイ１０は、すべてのＥＣＵ１〜３についてのチェックが終了したか否かを判定する（ステップＳＴ３）。
【００８４】
ステップＳＴ６の判定結果が否定的である場合は、ゲートウェイ１０は、当該ＥＣＵ１〜３に対して、メモリ領域の開始時点からリプログラムを開始するように指示する（ステップＳＴ６）。
ステップＳＴ６の判定結果が肯定的である場合は、ゲートウェイ１０は、中断があった当該ＥＣＵ１〜３に対して、前回の中断点Ｐから新バージョンの書き込みを再開するように指示する（ステップＳＴ７）。
【００８５】
ステップＳＴ３の判定結果が否定的である場合は、ゲートウェイ１０は、ステップＳＴ２の前に戻って処理を繰り返す。
ステップＳＴ３の判定結果が肯定的である場合は、ゲートウェイ１０は、通常モード移行要求とリセット要求を、各ＥＣＵ１〜３に送信したあと、管理サーバ５に更新完了通知を送信する（ステップＳＴ５）。
【００８６】
このように、ゲートウェイ１０は、障害からの復帰後に新バーションの書き換えを途中で中断したＥＣＵ１〜３がどれかを探索し（ステップＳＴ１，ＳＴ２，ＳＴ６）、当該ＥＣＵ１〜３に対して中断点Ｐからの新バーションの書き換え再開を指示する（ステップＳＴ７）。
【００８７】
従って、単独領域ＥＣＵ１〜３の同時更新中においていずれかのＥＣＵ１〜３における書き換え処理が何らかの障害で中断した場合に、中断した書き換え処理を再開させることができる。
このため、旧バーションの制御プログラムで動作するＥＣＵ３０と新バーションの制御プログラムで動作するＥＣＵ３０とが混在することにより、動作保障されていない制御プログラムが同時に動作して動作不良となるのを未然に防止することができる。
【００８８】
なお、上記の更新復帰処理も、同時更新の必要性があるすべてのＥＣＵ１〜３が更新プログラムΔ１〜Δ３を用いた制御プログラムの更新を完了するまで、当該ＥＣＵ１〜３に制御プログラムの更新を継続させる「更新継続処理」の一種である。
【００８９】
〔自身でΔを適用できないＥＣＵに対する更新処理〕
上述の実施形態では、ＥＣＵ１〜３がΔを自身で展開可能である場合を例示したが、中にはΔを自身で適応できないＥＣＵ１も存在する。この場合、図１０に示すように、まずＥＣＵ１からファームを吸出してゲートウェイ１０に転送する。
その後、ゲートウェイ１０上でΔ１を展開する。Δ１が適応されたファームは、ＥＣＵ１に転送され、ＥＣＵ１のＲＯＭが書き換えられる。ＥＣＵ１は、書き換え終了後にゲートウェイ１０に完了通知を行う。
【００９０】
〔自身でΔを適用できないＥＣＵに対する更新復帰処理〕
ゲートウェイ１０は、Δ１を展開中の場合には、図８（ｅ）の場合と同様に中断点Ｐからの再開を試みる。転送状態をゲートウェイ１０で記録しておき、転送途中の場合は、転送のやり直しを試みる。
【００９１】
〔その他の変形例〕
今回開示した実施形態はすべての点で例示であって制限的なものではない。本発明の権利範囲は、上述の実施形態に限定されるものではなく、特許請求の範囲に記載された構成と均等の範囲内でのすべての変更が含まれる。
【００９２】
例えば、上述の実施形態において、制御プログラムの動作領域が複数存在する記憶装置を有する複数領域ＥＣＵ３０に対する更新継続処理として、いずれかのＥＣＵ３０において途中で更新が中断した場合に、中断した当該ＥＣＵ２０に中断点Ｐから更新を再開させる更新復帰処理を実行させることにしてもよい。
【符号の説明】
【００９３】
１  車両
２  広域通信網
５  管理サーバ
６  ＤＬサーバ
１０  ゲートウェイ（中継装置）
１１  ＣＰＵ（処理部）
１２  ＲＡＭ
１３  記憶部
１４  車内通信部
１５  無線通信部
３０  ＥＣＵ（制御装置）
３１  ＣＰＵ
３２  ＲＡＭ
３３  記憶部
３４  通信部
３５  起動部
５１  ＣＰＵ（処理部）
５２  ＲＯＭ
５３  ＲＡＭ
５４  記憶部
５５  通信部
【図１】
0006390644.tif 000002
【図２】
0006390644.tif 000003
【図３】
0006390644.tif 000004
【図４】
0006390644.tif 000005
【図５】
0006390644.tif 000006
【図６】
0006390644.tif 000007
【図７】
0006390644.tif 000008
【図８】
0006390644.tif 000009
【図９】
0006390644.tif 000010
【図１０】
0006390644.tif 000011