WO2018070156A1

WO2018070156A1 - ソフトウェア更新装置、ソフトウェア更新方法、ソフトウェア更新システム

Info

Publication number: WO2018070156A1
Application number: PCT/JP2017/032506
Authority: WO
Inventors: 秀敏寺岡; 櫻井　康平; 長田　健一; 黒澤　憲一; 中原　章晴
Original assignee: 日立オートモティブシステムズ株式会社
Priority date: 2016-10-14
Filing date: 2017-09-08
Publication date: 2018-04-19
Also published as: US11467818B2; EP3528118A1; EP3528118B1; CN109804355A; EP3528118A4; JP6760813B2; CN109804355B; US20200225930A1; JP2018063659A

Abstract

ソフトウェア更新装置は、制御装置と接続され、制御装置のソフトウェアを更新前状態から更新完了状態へと遷移させる更新処理を行う更新制御部と、リカバリ制御情報を取得するリカバリ制御情報管理部と、更新処理の異常によりソフトウェアが更新完了状態へと遷移されていない場合に、リカバリ制御情報に基づきソフトウェアを更新完了状態に遷移させるリカバリ処理を実行するリカバリ制御部とを備える。

Description

ソフトウェア更新装置、ソフトウェア更新方法、ソフトウェア更新システム

　本発明は、ソフトウェア更新装置、ソフトウェア更新方法、およびソフトウェア更新システムに関する。

　近年、運転支援機能や自動運転技術の進展により、自動車用の電子制御装置（ＥＣＵ：Ｅｌｅｃｔｒｉｃ　Ｃｏｎｔｒｏｌ　Ｕｎｉｔ）に搭載されるソフトウェアの規模が増大している。また、それに伴ってソフトウェア不具合に起因するリコールの回数だけでなく、１回あたりに対応が必要な台数も増加している。そのため、ＥＣＵに搭載されるソフトウェアを遠隔で更新する技術へのニーズが高まっている。遠隔でソフトウェアを更新するにあたっては、従来ディーラ等で整備士が更新作業を行っていた場合とは異なり、できるだけ処理を自動化する必要がある。そのため、たとえば電源断等の異常が発生して更新処理が中断した場合でも、整備士等の操作を前提とせずに正常な状態に復帰させることができることが重要となる。
　たとえば、特許文献１には、実行ソフトウェアを格納するエリアを２面用意し、ソフトウェアの更新異常が発生した場合に、正常なソフトウェアを選択して実行することで更新異常時もシステムに影響を与えない技術が開示されている。

日本国特許第４５４８６０１号

　特許文献１に記載の発明は、メモリリソースが乏しい装置に適用することができず、ソフトウェアを更新する装置の多様性に対応することが困難である。

　本発明の第１の態様によるソフトウェア更新装置は、制御装置と接続され、前記制御装置のソフトウェアを更新前状態から更新完了状態へと遷移させる更新処理を行う更新制御部と、リカバリ制御情報を取得するリカバリ制御情報管理部と、前記更新処理の異常により前記ソフトウェアが前記更新完了状態へと遷移されていない場合に、前記リカバリ制御情報に基づき前記ソフトウェアを前記更新完了状態に遷移させるリカバリ処理を実行するリカバリ制御部とを備える。
　本発明の第２の態様によるソフトウェア更新方法は、制御装置と接続されるソフトウェア更新装置により実行され、前記制御装置のソフトウェアを更新前状態から更新完了状態へと遷移させる更新処理を行うことと、リカバリ制御情報を取得することと、前記更新処理の異常により前記ソフトウェアが前記更新完了状態へと遷移されていない場合に、前記リカバリ制御情報に基づき前記ソフトウェアを前記更新完了状態に遷移させるリカバリ処理を実行することとを有する。
　本発明の第３の態様にソフトウェア更新システムは、上記ソフトウェア更新装置と、前記ソフトウェア更新装置に前記リカバリ制御情報を送信するサーバとを備える。

　本発明によれば、多様な装置に対応したリカバリ処理を実行できる。

ソフトウェア更新システムの構成を示す図図２（ａ）はゲートウェイのハードウェア構成を示すブロック図、図２（ｂ）はゲートウェイ上で動作するゲートウェイプログラムの構成を示すブロック図更新状態Ｄ１の一例を示す図図４（ａ）はエンジン制御ＥＣＵのハードウェア構成を示すブロック図、図４（ｂ）はエンジン制御ＥＣＵ上で動作する制御プログラムの構成を示すブロック図図５（ａ）は容量が少ないＦＲＯＭの構成例を示す図、図５（ｂ）は容量が多いＦＲＯＭの構成例を示す図図６（ａ）は第１の実施の形態における更新パッケージの構成を示す図、図６（ｂ）は、第１の実施の形態におけるＥＣＵリカバリ制御情報の構成を示す図エンジン制御ＥＣＵのソフトウェアを更新する更新処理全体を示すシーケンス図図７のステップＳ４においてゲートウェイとエンジン制御ＥＣＵの間で実行されるソフトウェア更新処理の流れを示すシーケンス図図９（ａ）はメモリの少ないＥＣＵにおける復元処理Ｓ４０７の処理を示す概念図、図９（ｂ）は、メモリが多いＥＣＵにおける復元処理Ｓ４０７の処理を示す概念図図１０（ａ）はメモリの少ないＥＣＵの起動シーケンス図、図１０（ｂ）はメモリの多いＥＣＵの起動シーケンス図ゲートウェイ１０が起動時に行うリカバリ制御処理を示すフローチャートリカバリ処理Ｓ７０７の一例を示すフローチャート図１３（ａ）および図１３（ｂ）は自動運転ＥＣＵに対応する更新パッケージの一例を示す図、図１３（ｃ）は画面表示例を示す図自動運転ＥＣＵのリカバリ処理の一例を示すシーケンス図図１５（ａ）および図１５（ｂ）はＡＤＡＳ　ＥＣＵに対応する更新パッケージの一例を示す図、図１５（ｃ）は画面表示例を示す図ＡＤＡＳ　ＥＣＵのリカバリ処理の一例を示すシーケンス図図１７（ａ）および図１７（ｂ）はエンジン制御ＥＣＵに対応する更新パッケージの一例を示す図、図１７（ｃ）は画面表示例を示す図エンジン制御ＥＣＵのリカバリ処理の一例を示すシーケンス図図１９（ａ）および図１９（ｂ）はブレーキ制御ＥＣＵに対応する更新パッケージの一例を示す図、図１９（ｃ）は画面表示例を示す図ブレーキ制御ＥＣＵのリカバリ処理の一例を示すシーケンス図図２１（ａ）および図２１（ｂ）はＨＶＡＣ　ＥＣＵに対応する更新パッケージの一例を示す図、図２１（ｃ）は画面表示例を示す図ＨＶＡＣ　ＥＣＵのリカバリ処理の一例を示すシーケンス図図２３（ａ）および図２３（ｂ）はエアバッグＥＣＵに対応する更新パッケージの一例を示す図、図２３（ｃ）は画面表示例を示す図エアバッグＥＣＵのリカバリ処理の一例を示すシーケンス図変形例６における更新パッケージの一例を示す図第２の実施の形態におけるエンジン制御ＥＣＵ上で動作する制御プログラムの構成を示すブロック図ゲートウェイがエンジン制御ＥＣＵからリカバリ制御情報を取得する処理を示すシーケンス図図２８（ａ）は第３の実施の形態における更新パッケージの構成を示す図、図２８（ｂ）は、第３の実施の形態におけるＥＣＵリカバリ制御情報の構成を示す図図２９（ａ）は自動運転ＥＣＵに対応するリカバリ制御情報の一例を示す図、図２９（ｂ）は画面表示例を示す図、図２９（ｃ）は、更新状態Ｄ１の一例を示す図図３０（ａ）は中断要因によって異なるリカバリ制御処理の一例を示すシーケンス図、図３０（ｂ）は、ＦＲＯＭ故障時のリカバリ制御処理の一例を示すシーケンス図

―第１の実施の形態―
　以下、図１～図２４を参照して、第１の実施の形態に係るソフトウェア更新システムを説明する。なお本実施の形態ではソフトウェアの更新について説明するが、ソフトウェアに限定されずパラメータやデータなどに適用可能である。

　＜更新とリカバリの定義＞
　本実施の形態におけるソフトウェアの「更新」と「リカバリ」を以下のように定義する。すなわち本実施の形態におけるソフトウェアの「更新」とは、ソフトウェアを更新前状態から更新完了状態へと遷移させることである。また本実施の形態におけるソフトウェアの「リカバリ」とは、更新処理の異常によりソフトウェアが更新完了状態へと遷移されていない場合に、更新完了状態に遷移させることである。
　ただしソフトウェアは、単一のプログラムから構成されてもよいし、複数のプログラムから構成されてもよい。さらにソフトウェアはプログラムだけでなくプログラムの実行に必要な各種パラメータ、テキスト情報、音声情報、画像情報などを含んでいてもよい。

　＜構成＞
　（システム構成）
　図１は、第１の実施の形態にかかるソフトウェア更新システムＳの構成を示す図である。ソフトウェア更新システムＳは車両１、およびサーバ２を備える。車両１とサーバ２は、アクセスネットワークや拠点を接続するインターネット３、および通信サービスプロバイダが提供するアクセスネットワーク４を介して接続される。
　車両１は、ゲートウェイ１０、通信モジュール１１、Ｈｕｍａｎ　Ｍａｃｈｉｎｅ　Ｉｎｔｅｒｆａｃｅ（ＨＭＩ）１２、エンジン制御ＥＣＵ１３、ブレーキ制御ＥＣＵ１４、自動運転ＥＣＵ１５、先進運転支援システム（ＡＤＡＳ）　ＥＣＵ１６、エアバッグＥＣＵ１７、Ｈｅａｔｉｎｇ　Ｖｅｎｔｉｌａｔｉｏｎ　Ａｉｒ　Ｃｏｎｄｉｔｉｏｎｉｎｇ（ＨＶＡＣ）　ＥＣＵ１８、および車両管理ＥＣＵ１９等の車両１が走行等の機能を実現するために必要とするＥＣＵ群と、これらＥＣＵ群をつなぐ車内ネットワーク１０ａ、１０ｂとを備える。

　本実施の形態では、エンジン制御ＥＣＵ１３の制御プログラムを現行のバージョン２から新バージョンであるバージョン３に更新する例を説明する。なおこの制御プログラムは、現行のバージョン２の直前の旧バージョンは１である。
　車内ネットワークはＣｏｎｔｒｏｌ　Ａｒｅａ　Ｎｅｔｗｏｒｋ（ＣＡＮ）（登録商標）、Ｌｏｃａｌ　Ｉｎｔｅｒｃｏｎｎｅｃｔ　Ｎｅｔｗｏｒｋ（ＬＩＮ）、ＦｌｅｘＲａｙ、Ｅｔｈｅｒｎｅｔ（登録商標）などで構成される。本実施の形態では、車内ネットワーク１０ｂはＣＡＮで、車内ネットワーク１０ａはＥｔｈｅｒｎｅｔで構成される。また、図１では図示しないが、各種ＥＣＵなどの車両内の各構成要素は電力線で蓄電池に接続され、電力供給を受けている。

　ゲートウェイ１０は、各種ＥＣＵ間通信データの中継を行うとともに、ソフトウェア更新装置として、自機器および車内ネットワークを介して接続されたＥＣＵに搭載されるソフトウェアの更新を行う。
　通信モジュール１１は、ゲートウェイ１０やＨＭＩ１２、各種ＥＣＵとサーバ２との通信を中継する。ＨＭＩ１２は、車両１の乗員であるユーザへの情報提示やユーザからの入力を受け付けるための装置であり、画面表示を行う表示装置および各種スイッチ等の入力装置、またはこれらを組み合わせたタッチパネル等により構成される。エンジン制御ＥＣＵ１３は、エンジンの制御を行う。ブレーキ制御ＥＣＵ１４は、ブレーキの制御を行う。自動運転ＥＣＵ１５は、自動運転時に環境の認識や車両の起動指示等を行う。ＡＤＡＳ　ＥＣＵ１６は、自動ブレーキなどの運転支援制御を行う。エアバッグＥＣＵ１７は、エアバッグの制御を行う。ＨＶＡＣ　ＥＣＵ１８は、車内の空調制御を行う。車両管理ＥＣＵ１９は、車両状態の管理を行う。

　サーバ２は不図示のＣＰＵ，ＲＯＭ，およびＲＡＭを備え、ソフトウェア更新に必要な更新パッケージ５をゲートウェイ１０に送信する。更新パッケージ５の構成は後述する。ゲートウェイ１０は、更新パッケージ５に含まれるデータに基づいて各ＥＣＵのソフトウェアを更新する。

（ゲートウェイの構成）
　図２（ａ）は、ゲートウェイ１０のハードウェア構成を示すブロック図である。ゲートウェイ１０は、マイコン１０１、ＦＲＯＭ（ＦｌａｓｈＲＯＭ）１０２、ＣＡＮ用の通信Ｉ／Ｆ１０４、およびＥｔｈｅｒｎｅｔ用の通信Ｉ／Ｆ１０５を備える。
　マイコン１０１は、ＣＰＵ１０１１、ＳＲＡＭ１０１２、ＦＲＯＭ１０１３、ＣＡＮ通信コントローラ１０１４、およびＥｔｈｅｒｎｅｔ通信コントローラ１０１５を備える。マイコン１０１のＣＰＵ１０１１は、ＦＲＯＭ１０１３に格納されるプログラムを実行し、ゲートウェイ１０内の他の構成要素を制御するとともに、車内ネットワークにより接続された他の機器とデータ送受信指示を行うなどしてゲートウェイ１０を機能させる。

　ＦＲＯＭ１０２は、不揮発メモリであり、受信した更新パッケージ５が格納される。
　通信Ｉ／Ｆ１０４は、ＣＡＮ通信用のインタフェースであり、マイコン１０１の指示に基づき車内ネットワーク１０ｂを介して、車内ネットワーク１０ｂに接続されたＥＣＵとの間でデータの送受信を行う。
　通信Ｉ／Ｆ１０５は、Ｅｔｈｅｒｎｅｔ通信用のインタフェースであり、マイコン１０１の指示に基づき車内ネットワーク１０ａを介して、車内ネットワーク１０ａに接続された機器との間でデータの送受信を行う。

　図２（ｂ）は、ゲートウェイ１０上で動作するゲートウェイプログラム１００の構成を示すブロック図である。
　ゲートウェイ１０の機能を実現するゲートウェイプログラム１００は、マイコン１０１のＦＲＯＭ１０１３に格納されＣＰＵ１０１１により実行される。図２（ｂ）では、機能的なまとまりをブロックとして表現しており、各ブロックが複数に分割されてもよいし、いくつかのブロックが統合されてもよい。また制御プログラムは、１つのソフトウェアにより実現されてもよいし、２以上のソフトウェアの組合せにより実現されてもよい。
　ゲートウェイプログラム１００は、更新制御部１０００１、更新データ管理部１０００２、更新状態管理部１０００３、リカバリ制御部１０００４、リカバリ制御情報管理部１０００５、車両状態管理部１０００６、および通信制御部１０００７を含む。

　更新制御部１０００１は、通信制御部１０００７を介して車内ネットワーク１０ａに接続された機器と通信を行い、更新パッケージ５の取得や車両の状態やソフトウェア更新処理の状況の送信を行う。更新制御部１０００１が取得した更新パッケージ５は、ＦＲＯＭ１０２に格納される。詳しくは後述するが、更新パッケージ５は、更新制御情報５０１とリカバリ制御情報５０２とから構成される。また更新制御部１０００１は、通信制御部１０００７を介して車内ネットワーク１０ｂに接続された機器と通信を行い、ＥＣＵを制御してＥＣＵに搭載されるソフトウェアを更新する。ここで、ソフトウェアの更新は、更新データ管理部１０００２を介して取得した更新制御情報５０１と車両状態管理部１０００６を介して取得した車両システム状態に基づいて実施される。

　更新データ管理部１０００２は、ＦＲＯＭ１０２から更新制御情報５０１を取得し、更新制御部１０００１に提供する。
　更新状態管理部１０００３は、更新制御部１０００１から更新状態を取得し、ＦＲＯＭ１０１３に更新状態Ｄ１として格納する。また、格納した更新状態Ｄ１をリカバリ制御部１０００４に提供する。
　リカバリ制御部１０００４は、通信制御部１０００７を介して車内ネットワーク１０ｂに接続された機器と通信を行い、ＥＣＵを制御してソフトウェアのリカバリ処理を実施する。ここで、ＥＣＵのリカバリ処理は、更新状態管理部１０００３を介して取得した更新状態Ｄ１と、リカバリ制御情報管理部１０００５を介して取得したリカバリ制御情報５０２と、車両状態管理部１０００６を介して取得した車両システム状態に基づいて実施される。

　リカバリ制御情報管理部１０００５は、ＦＲＯＭ１０２からリカバリ制御情報５０２を取得し、リカバリ制御部１０００４に提供する。
　車両状態管理部１０００６は、通信制御部１０００７を介して車内ネットワーク１０ａおよび１０ｂに接続された機器と通信を行い車両システムの状態を取得し、車両状態を更新制御部１０００１及びリカバリ制御部１０００４に提供する。車両状態とはたとえば、イグニッションのオンやオフ、走行の開始などである。

　通信制御部１０００７は、更新制御部１０００１等の指示に従って、ＣＡＮ通信コントローラ１０１４およびＥｔｈｅｒｎｅｔ通信コントローラ１０１５を制御し、車内ネットワーク１０ａおよび１０ｂに接続された機器と通信を行う。車内ネットワーク１０ａに接続された機器と通信する際には、通信制御部１０００７は、ＴＣＰ／ＩＰやＵＤＰ／ＩＰなどのパケットを解析・生成する。また車内ネットワーク１０ａに接続された機器と通信する際には、通信制御部１０００７は、ＣＡＮフレームを解析・生成する。また通信制御部１０００７は、Ｕｎｉｖｅｒｓａｌ　Ｄｉａｇｎｏｓｔｉｃ　Ｓｅｒｖｉｃｅ（ＵＤＳ）等の診断通信プロトコルに準拠したコマンドの生成・解析を行う。

　図３は、ゲートウェイ１０の更新状態管理部１０００３が管理する更新状態Ｄ１の一例を示す図である。図３では、更新状態Ｄ１をテーブルとして管理し、ＥＣＵ毎の更新状態を記録する場合の例が示されている。
　更新状態Ｄ１は、ＥＣＵ　ＩＤ　Ｄ１０１、更新開始状態Ｄ１０２、処理中ブロックＤ１０３、完了コマンドＤ１０４、成功ブロックＤ１０５のフィールドを備える。

　ＥＣＵ　ＩＤ　Ｄ１０１は、ＥＣＵを識別するための情報が格納されるフィールドである。更新開始状態Ｄ１０２は、当該ＥＣＵの更新処理が開始済みかどうかを示す識別情報が格納されるフィールドであり、たとえば「開始未」、「開始済み」または「更新完」が格納される。処理中ブロックＤ１０３は、当該ＥＣＵの更新処理において、処理中のブロックの識別情報が格納されるフィールドであり、ブロック番号等が格納される。完了コマンドＤ１０４は、当該ＥＣＵの更新処理において、最後に成功したコマンドの識別情報が格納されるフィールドであり、「データ転送開始要求」等のコマンド識別情報が格納される。成功ブロックＤ１０５は、処理が成功したブロックの識別情報が格納されるフィールドであり、ブロック番号等が格納される。

　レコードＤ１１は自動運転ＥＣＵ１５の更新状態を示すレコードであり、ＥＣＵ　ＩＤ　Ｄ１０１のフィールドには「自動運転ＥＣＵ」が格納され、更新開始状態Ｄ１０２のフィールドには更新処理中であることを示す「開始済み」が格納され、処理中ブロックＤ１０３のフィールドにはブロックｎ－１が処理中であることを示す「Ｂｌｏｃｋ　ｎ－１」が格納され、完了コマンドＤ１０４のフィールドには、データ転送開始要求が受諾済みであることを示す「データ転送開始要求」が格納され、成功ブロックＤ１０５のフィールドには最後に処理完了したブロックがブロックｎであることを示す「Ｂｌｏｃｋ　ｎ」が格納されている。

　レコードＤ１２は、エンジン制御ＥＣＵ１３の更新状態を示すレコードであり、ＥＣＵ　ＩＤ　Ｄ１０１のフィールドには「エンジン制御ＥＣＵ」が格納され、更新開始状態Ｄ１０２のフィールドには更新処理を開始していないことを示す「開始未」が格納されている。ここでは、エンジン制御ＥＣＵの更新は開始されていないため、レコードＤ１２の他のフィールドには値が設定されていない。
　ここではレコードＤ１１とレコードＤ１２の２つのレコードを説明したが、これらのレコードは次の場合に作成される。すなわち、ゲートウェイ１０が受信した更新パッケージ５において、更新対象のＥＣＵとして記載されていた場合に作成される。またこの更新状態Ｄ１は後述するように逐次記録される。このように、更新状態Ｄ１を逐次記録することにより、更新中断後に正常に復帰して起動した際に更新が完了せずに中断していることや、更新が中断された箇所を認識して適切なリカバリ処理を開始することができる。

（ＥＣＵの構成）
　図４（ａ）は、エンジン制御ＥＣＵ１３のハードウェア構成例を示すブロック図である。ただし本実施の形態においてソフトウェアが更新される対象となるＥＣＵはいずれも、少なくとも図４（ａ）に示すハードウェア構成を備える。エンジン制御ＥＣＵ１３は、マイコン１３１、およびＣＡＮ用の通信Ｉ／Ｆ１３３を備える。
　マイコン１３１は、ＣＰＵ１３１１、ＳＲＡＭ１３１２、ＦＲＯＭ１３１３、通信コントローラ１３１４、およびＩ／Ｏコントローラ１３１５を備える。マイコン１３１は、ＦＲＯＭ１３１３に格納される制御プログラムを実行し、エンジン制御ＥＣＵ１３内の他の構成要素やＩ／Ｏを介して接続されたセンサ／アクチュエータ１３２を制御するとともに、車内ネットワークで接続された他の機器とデータ送受信指示を行うなどしてエンジン制御を実施する。センサ／アクチュエータ１３２は、マイコン１３１の指示によってエンジン制御に必要となるデータを取得しつつ、エンジンの制御を実行する。

　図４（ｂ）は、エンジン制御ＥＣＵ１３上で動作する制御プログラム１３０の構成を示すブロック図である。ただし本実施の形態においてソフトウェアが更新される対象となるＥＣＵはいずれも、少なくとも図４（ｂ）に示す制御プログラム１３０と同様の構成を備える。
　ＥＣＵ１３の機能を実現する制御プログラム１３０は、マイコン１３１のＦＲＯＭ１３１３に格納されＣＰＵ１３１１で実行される。図４（ｂ）では、機能的なまとまりをブロックとして表現しており、各ブロックが複数に分割されてもよいし、いくつかのブロックが統合されてもよい。また制御プログラムは、１つのソフトウェアにより実現されてもよいし、２以上のソフトウェアの組合せにより実現されてもよい。

　制御プログラム１３０は、更新制御部１３００１、差分／圧縮復元部１３００２、更新状態管理部１３００３、ＦＲＯＭ制御部１３００４、通信制御部１３００５、および制御処理部１３００６を備える。
　更新制御部１３００１は、通信制御部１０００５を介してゲートウェイ１０からの動作指令やソフトウェアの更新に用いるデータを受信し、差分／圧縮復元部１３００２およびＦＲＯＭ制御部１３００４を制御してソフトウェアの更新を制御する。差分／圧縮復元部１３００２は、更新制御部１３００１の指示に従い、受信した差分データや圧縮データから最新版のソフトウェア、すなわちバージョン３のソフトウェアを復元する。

　更新状態管理部１３００３は、更新制御部１３００１から更新状態を取得し、ＦＲＯＭ１３１３に更新状態Ｄ２１として格納する。また、格納した更新状態Ｄ２１を更新制御部１３００１に提供する。ＦＲＯＭ制御部１３００４は、更新制御部１３００１の指示に従い、最新版のソフトウェアをＦＲＯＭ１３１３に書き込む。通信制御部１３００５は、更新制御部１３００１等の指示に従って、通信コントローラ１３１４を制御し、車内ネットワーク１０ｂに接続された機器と通信を行う。通信の際には、ＣＡＮフレームを解析・構成する。また通信制御部１３００５は、ＵＤＳ等の診断通信プロトコルに準拠したコマンドの生成・解析を行う。制御処理部１３００６は、Ｉ／Ｏコントローラ１３１５を制御し、センサ／アクチュエータ１３２を制御してエンジン制御を実施する。

　図５は、ＥＣＵのＦＲＯＭの構成例を示す構成図である。ＦＲＯＭ１３１３の容量の多少に基づき２とおりの構成を説明する。ただし以下では、ＦＲＯＭ１３１３の容量が多いことを「メモリが多い」とも呼び、ＦＲＯＭ１３１３の容量が少ないことを「メモリが少ない」とも呼ぶ。ＦＲＯＭ１３１３の容量の多少、すなわちＥＣＵのメモリが多いか少ないかは、ＦＲＯＭ１３１３の実用量、ＦＲＯＭ１３１３に格納されるプログラムのサイズ、ＦＲＯＭ１３１３に格納されるプログラムの性質、ＦＲＯＭ１３１３に格納されるデータ量の傾向などに基づき判断される。一般に複雑な処理を実行するＥＣＵは本実施の形態におけるメモリが多いＥＣＵに分類され、簡素な処理のみを実行するＥＣＵは本実施の形態におけるメモリが少ないＥＣＵに分類される。たとえば、エンジン制御ＥＣＵ１３、ブレーキ制御ＥＣＵ１４、ＨＶＡＣ　ＥＣＵ１８、エアバッグＥＣＵ１７などはメモリの少ないＥＣＵに分類されることが多く、自動運転ＥＣＵ１５、ＡＤＡＳ　ＥＣＵ１６などはメモリが多いＥＣＵに分類されることが多い。

　図５（ａ）は容量が少ない場合のＦＲＯＭ１３１３の構成例である。
　ＦＲＯＭ１３１３は、プログラムエリア１３１３ａＰ０およびＤａｔａエリア１３１３ａＤ０から構成される。
　プログラムエリア１３１３ａＰ０は、複数のブロックＢｌｏｃｋ０～ＢｌｏｃｋＮで構成され、ブートローダＰ１と制御プログラムＰ２が格納される。この制御プログラムＰ２のバージョンは、現行のバージョン２（図中では「Ｖｅｒ．２」と記載）である。Ｄａｔａエリア１３１３ａＤ０には、パラメータＤ２が格納される。パラメータＤ２は、更新状態Ｄ２１、および制御パラメータＤ２２を含む。更新状態Ｄ２１は、ソフトウェア更新の進捗等の状態を示す情報であり、後に詳述する。制御パラメータＤ２２は、ＥＣＵ本来のエンジン制御やブレーキ制御のために利用するパラメータ群である。

　図５（ｂ）は、容量が多い場合のＦＲＯＭ１３１３の構成例である。　
　ＦＲＯＭ１３１３は、プログラムエリアおよびＤａｔａエリア１３１３ｂＤ０から構成される。プログラムエリアは２つの領域、すなわちＢＡＮＫ０とＢＡＮＫ１から構成され、以下ではそれぞれをプログラムエリア１３１３ｂＰ０、プログラムエリア１３１３ｂＰ１と呼ぶ。

　プログラムエリア１３１３ｂＰ０、およびプログラムエリア１３１３ｂＰ１は、それぞれ複数のブロックＢｌｏｃｋ０～ＢｌｏｃｋＮから構成される。プログラムエリア１３１３ｂＰ０にはブートローダＰ３と制御プログラムＰ４が格納される。この制御プログラムＰ４のバージョンは、現行のバージョン２である。また、プログラムエリア１３１３ｂＰ１には制御プログラムＰ５が格納される。この制御プログラムＰ５のバージョンは、旧版のバージョン１である。
　Ｄａｔａエリア１３１３ｂＤ０には、パラメータＤ３が格納される。パラメータＤ３は、更新状態Ｄ２１、制御パラメータＤ２２、および起動情報Ｄ３３を含む。
　起動情報Ｄ３３には、２つのプログラムエリアのいずれに記録された制御プログラムを実行するかが設定され、たとえば「プログラムエリア１３１３ｂＰ０」や「プログラムエリア１３１３ｂＰ１」が設定される。更新状態Ｄ２１、および制御パラメータＤ２２は前述のとおりである。

　図６（ａ）は、ゲートウェイ１０がサーバ２から取得する更新パッケージ５の構成例である。更新パッケージ５は、更新制御情報５０１とリカバリ制御情報５０２から構成される。
　更新制御情報５０１は、１つの共通更新制御情報５０１１と、１つ以上のＥＣＵ更新制御情報５０１２と、１つ以上のＥＣＵ更新データ５０１３から構成される。ＥＣＵ更新制御情報５０１２、およびＥＣＵ更新データ５０１３は、更新対象であるＥＣＵごとに存在し、共通更新制御情報５０１１は更新対象であるＥＣＵの台数に関わらず１つのみ存在する。
　共通更新制御情報５０１１には、車両システム全体の状態確認に用いられる手順や閾値等の情報が含まれる。たとえば共通更新制御情報５０１１には、更新開始に必要な状態確認として、電池残量の確認や開始可能な残量閾値、ＨＶＡＣの有無の確認、車両走行状態の確認、に必要なＥＣＵ　ＩＤやＣＡＮ　ＩＤ、確認コマンドの情報が含まれる。

　ＥＣＵ更新制御情報５０１２は、更新対象のＥＣＵごとに構成され、ＥＣＵ更新制御情報５０１２にはそれぞれのＥＣＵのチェック項目や更新制御手順の情報が含まれる。
　ＥＣＵ更新データ５０１３は、更新対象のＥＣＵ毎に構成されるＥＣＵのソフトウェア更新に用いられるデータであり、たとえばソフトウェアそのもの、圧縮されたソフトウェアまたは新旧ソフトウェアの差分データである。

　リカバリ制御情報５０２は、１つ以上のＥＣＵリカバリ制御情報５０２１から構成され、１つ以上のＥＣＵリカバリデータ５０２２を含む場合がある。ＥＣＵリカバリ制御情報５０２１は更新対象であるＥＣＵごとに存在し、ＥＣＵリカバリデータ５０２２はＥＣＵリカバリ制御情報５０２１の内容に基づき存在の有無が決定される。すなわちＥＣＵリカバリデータ５０２２は、最大でＥＣＵリカバリ制御情報５０２１と同数だけ存在し、最小でゼロである。
　ＥＣＵリカバリデータ５０２２は、ＥＣＵのリカバリに追加データが必要な場合に付与されるデータであり、ソフトウェアそのもの、圧縮されたソフトウェアまたはＢｌｏｃｋ単位でソフトウェアのＸＯＲから生成したバックアップデータ等を備える。

　図６（ｂ）は、ＥＣＵリカバリ制御情報５０２１の構成を示す図である。ＥＣＵリカバリ制御情報５０２１は、ＥＣＵを識別するＥＣＵ　ＩＤ５０２１１、リカバリを開始するタイミングを示す開始タイミング５０２１２、ＨＭＩ１２の表示装置において画面表示する内容を示す表示内容５０２１３、リカバリの方式であるリカバリ方式５０２１４、および追加のリカバリデータを取得するためのリカバリデータＵＲＩ５０２１５から構成される。
　ＥＣＵ　ＩＤ５０２１１は、ＥＣＵを識別するための情報である。リカバリ開始タイミング５０２１２は、ゲートウェイ１０によるリカバリ処理を開始するタイミングを示す。リカバリ開始タイミング５０２１２はたとえば、システムが異常から復旧した直後を示す「即時」、走行を開始して電源供給が安定した後を示す「走行開始」、次にエンジンが動作状態から停止状態に遷移するときを示す「ＩＧＮ－ＯＦＦ」などが設定される。

　表示内容５０２１３は、システムが異常から復旧した際等にユーザに提示するメッセージが格納された表示メッセージ情報、および表示内容の概要が格納される。表示内容の概要とは、たとえば「注意喚起」、「警告」、および「緊急」である。表示内容５０２１３に基づき表示される具体的な例は後述する。
　リカバリ方式５０２１４は、当該ＥＣＵに対してどのような手順でリカバリを行うかを示し、「差分リジューム」、「圧縮リカバリ」、「サーバ連携」、「ブロックリカバリ」、などが設定される。「差分リジューム」は、異常中断した箇所から差分更新を再開するリカバリ処理の方式である。「圧縮リカバリ」は、圧縮されたソフトウェアをリカバリ制御情報５０２にＥＣＵリカバリデータ５０２２として同梱し、これを用いてソフトウェア全体を置き換えるいわゆるフル更新を行うリカバリ処理の方式である。「サーバ連携」は、サーバ２から圧縮されたソフトウェアを再ダウンロードしていわゆるフル更新を行うリカバリ処理の方式である。「ブロックリカバリ」は、ソフトウェアを複数のブロックに分割し各ブロックのＸＯＲを算出して得られたブロックＸＯＲデータをＥＣＵリカバリデータ５０２２として同梱し、ソフトウェアの欠損部分をブロックＸＯＲデータと欠損のないブロックから回復するリカバリ処理の方式である。

　リカバリデータＵＲＩ５０２１５には、リカバリ方式５０２１４が「サーバ連携」である場合に、ゲートウェイ１０がリカバリデータを取得するＵＲＩが設定される。リカバリ方式５０２１４が「サーバ連携」以外の場合は、リカバリデータＵＲＩ５０２１５は情報が設定されていないことを意味する「ＮＵＬＬ」が設定される。なおこのＵＲＩが示すリソースが格納されている場所は、サーバ２でもよいしサーバ２以外でもよい。

　図７は、エンジン制御ＥＣＵ１３のソフトウェアを更新する更新処理全体の流れを示すシーケンス図である。ここではエンジン制御ＥＣＵ１３のみが更新対象であり、他のＥＣＵは更新対象ではないとして説明する。
　サーバ２のオペレータは、エンジン制御ＥＣＵ１３の新たなソフトウェアが作成されると、このソフトウェアをエンジン制御ＥＣＵ１３に配信するための準備を行い、更新パッケージ５を作成してサーバ２に登録する（Ｓ１）。なお更新パッケージ５の作成はオペレータが行ってもよいし、作成された新たなソフトウェアと設定ファイルに基づきサーバ２が行ってもよい。

　配信準備完了後、エンジン起動時などにゲートウェイ１０は、通信モジュール１１を介してサーバ２から更新パッケージ５をダウンロードしてゲートウェイ１０のＦＲＯＭ１０２に保持する（Ｓ２）。その後、エンジン状態が起動中から停止に状態が遷移したときなどに、更新対象であるエンジン制御ＥＣＵ１３のバージョンのチェック、更新対象のＥＣＵの状態取得、およびＨＭＩ１２を用いたユーザへの承諾を得る前処理Ｓ３を実施したのち、エンジン制御ＥＣＵ１３のソフトウェア更新処理Ｓ４を行う。最後に、更新対象ＥＣＵ１３の書換え状態を確認する後処理Ｓ５を実施して、更新処理が完了する。更新処理である前処理Ｓ３、ソフトウェア更新処理Ｓ４、後処理Ｓ５の開始タイミングは、エンジン停止時以外にも、ダウンロード処理Ｓ２完了直後や、所定の時刻、などが考えられる。以下では符号Ｓ４で示したソフトウェア更新処理を詳細に説明する。

　図８は、図７のステップＳ４においてゲートウェイ１０とエンジン制御ＥＣＵ１３の間で実行されるソフトウェア更新処理の流れを示すシーケンス図である。ここでは、エンジン制御ＥＣＵ１３を更新する例を示すが、本動作は基本的に他のＥＣＵでも同様である。図８では状況により必要となる処理を破線の矢印で示している。
　以下の説明において、ゲートウェイ１０におけるデータの送受信は通信制御部１０００７を介して行われるものとし、エンジン制御ＥＣＵ１３におけるデータの送受信は通信制御部１３００５を介して行われるものとする。

　最初に、ゲートウェイ１０の更新制御部１０００１は、エンジン制御ＥＣＵ１３にセッション変更要求を送信する（Ｓ４０１）。このセッション変更要求は、ソフトウェア書換えを行うための特殊モードの識別情報を含む。エンジン制御ＥＣＵ１３の更新制御部１３００１は、ステップＳ４０２でゲートウェイ１０から送信されたセッション変更要求を受信すると、セッション変更要求にて指定されたモードに内部状態を遷移させたのち、ゲートウェイ１０に受諾応答を送信する（Ｓ４０２）。

　ゲートウェイ１０の更新制御部１０００１は、ステップＳ４０２でエンジン制御ＥＣＵ１３から送信された受諾応答を受信すると、更新状態管理部１０００３を介して更新状態Ｄ１に更新適用処理を開始したことを記録する（Ｓ４０２Ｒ）。次に、ゲートウェイ１０の更新制御部１０００１は、更新データ管理部１０００２を介してＥＣＵ更新制御情報５０１２を読み出し、ＥＣＵ更新制御情報５０１２に記述された処理ブロック毎の処理を開始する。すなわち更新制御部１０００１は、ＥＣＵ更新制御情報５０１２に記述された最初の処理ブロックを特定し、当該ブロックを「処理中ブロック」として更新状態管理部１０００３を介して更新状態Ｄ１に記録する（Ｓ４０３Ｒ）。

　そして更新制御部１０００１は、エンジン制御ＥＣＵ１３に当該ブロックのデータ転送開始要求を送信する（Ｓ４０３）。このデータ転送開始要求は、たとえば、データフォーマット、送信予定のデータサイズ、送信したデータの書込み先を示す書込み先アドレス等の情報を含む。エンジン制御ＥＣＵ１３の通信制御部１３００５は、ステップＳ４０３でゲートウェイ１０から送信されたデータ転送開始要求を受信すると、ゲートウェイ１０に受諾応答を送信する（Ｓ４０４）。この受諾応答には、エンジン制御ＥＣＵ１３が一度に受信可能なデータサイズ等の情報が含まれる。ゲートウェイ１０の更新制御部１０００１はこの受諾応答を受信すると、更新状態管理部１０００３を介して更新状態Ｄ１に成功したコマンドとして「データ転送開始要求」を記録する（Ｓ４０４Ｒ）。

　次に、ゲートウェイ１０の更新制御部１０００１は、現在処理中のブロックに該当する更新データを更新データ５０１３から読み出し、エンジン制御ＥＣＵ１３が一度に受信可能なデータサイズに分割し、エンジン制御ＥＣＵ１３に送信する（Ｓ４０５）。ここで、送信データはさらにＣＡＮフレームに分割されて送信される。エンジン制御ＥＣＵ１３の更新制御部１３００１は、ステップＳ４０５でゲートウェイ１０から送信されたデータを受信すると、差分／圧縮復元部１３００２に指示して復元処理Ｓ４０７を開始する。この復元処理Ｓ４０７は後に詳述する。ここで、復元処理に時間がかかる場合は、ゲートウェイ１０に待機応答を送信する（Ｓ４０６）。エンジン制御ＥＣＵ１３の更新制御部１３００１は、復元処理Ｓ４０７が完了すると、ゲートウェイ１０に受信応答Ｓ４０８を送信する。ゲートウェイ１０とエンジン制御ＥＣＵ１３は、分割した現在処理中のブロックに該当する更新データの転送がすべて完了するまで、ステップＳ４０５からＳ４０８までの処理（転送処理Ｓ４３０）を繰り返す。

　ゲートウェイ１０の更新制御部１０００１は、転送処理Ｓ４３０が完了すると、更新状態管理部１０００３を介して更新状態Ｄ１に成功したコマンドとして「データ転送」を記録し（Ｓ４０８Ｒ）、転送完了通知をエンジン制御ＥＣＵ１３に送信する（Ｓ４０９）。エンジン制御ＥＣＵ１３の更新制御部１３００１は、ステップＳ４０９でゲートウェイ１０から送信された転送完了通知を受信すると、ステップＳ４１１においてＦＲＯＭ制御部１３００４にデータ書込み指示を行う。この指示に応じて、ＦＲＯＭ制御部１３００４は、差分／圧縮復元部１３００２により復元され、ＳＲＡＭ１３１２またはＦＲＯＭ１３１３に一時的に格納されている新ソフトウェアまたはその一部をＦＲＯＭ１３１３に書き込む。ここで、ＦＲＯＭ１３１３へのデータ書き込みに時間がかかる場合には、ゲートウェイ１０に待機応答を送信する（Ｓ４１０）。更新制御部１３００１は、ＦＲＯＭ１３１３への書込みに成功すると、更新状態管理部１３００３を介して、完了したブロックとして書きこんだブロックを更新状態Ｄ２１に記録し（Ｓ４１１Ｒ）、ゲートウェイ１０に受諾応答を送信する（Ｓ４１２）。

　ゲートウェイ１０の更新制御部１０００１は、ステップＳ４１２でエンジン制御ＥＣＵ１３から送信された受諾応答を受信すると、更新状態管理部１０００３を介して更新状態Ｄ１に当該ブロックの書換え処理が完了したことを記録する（Ｓ４１２Ｒ）。ゲートウェイ１０とエンジン制御ＥＣＵ１３は、処理対象の全ブロックに該当する転送および書き込み処理をすべて完了するまで、ステップＳ４０３ＲからＳ４１２Ｒまでの処理（ブロック復元・書込み処理Ｓ４２０）を繰り返す。処理対象の全ブロックの復元・書込み処理Ｓ４２０が完了すると、ゲートウェイ１０の更新制御部１０００１は、更新状態管理部１０００３を介して更新状態Ｄ１に書き換え処理が完了したことを記録する（Ｓ４１５Ｒ）。

　次に、ゲートウェイ１０の更新制御部１０００１は、エンジン制御ＥＣＵ１３にセッション変更要求を送信する（Ｓ４１３）。このセッション変更要求は、通常モードに復帰するための通常モードの識別情報を含む。エンジン制御ＥＣＵ１３の更新制御部１３００１は、ステップＳ４１３でゲートウェイ１０から送信されたセッション変更要求を受信すると、セッション変更要求にて指定された通常モードに内部状態を遷移させたのち、ゲートウェイ１０に受諾応答を送信する（Ｓ４１４）。
　このように、更新状態を逐次記録することで、更新中断後、正常に復して起動した時に更新が完了せずに中断していること、および更新がどこまで進んだ状態で中断したか、を認識して適切なリカバリ処理を開始することができる。

　図９は、ＥＣＵにおける復元処理Ｓ４０７の処理を示す概念図である。
　図９（ａ）は、メモリの少ないＥＣＵにおける復元処理Ｓ４０７の処理を示す概念図である。差分／圧縮復元部１３００２は、更新制御部１３００１から復元指示を受けると、ゲートウェイ１０から受信し、ＳＲＡＭ１３１２に格納された更新データ５０１３ａの一部を読み出す。圧縮更新の場合は、更新データは圧縮されているため、これを伸長し復元領域Ｄ５にバージョン３の制御プログラムＰ２２として出力する。差分更新の場合は、更新データは差分データであるため、差分／圧縮復元部１３００２はまず復元のために必要な現行のバージョン２の制御プログラムＰ２１の一部または全部を読み出す。そして差分／圧縮復元部１３００２は、これらを組み合わせてバージョン３の制御プログラムＰ２２を復元し、復元領域Ｄ５に出力する。

　なお、本実施の形態では復元領域Ｄ５は、ＦＲＯＭ１３１３のＤａｔａエリア１３１３ａＤ０内に確保しているが、たとえば、プログラムエリアの空き領域（１３１３ａＰ０のＢｌｏｃｋＮ）や、ＳＲＡＭ１３１２に確保してもよい。復元領域Ｄ５としてＦＲＯＭ１３１３のＤａｔａエリア１３１３ａＤ０やプログラムエリアの空き領域（１３１３ａＰ０のＢｌｏｃｋＮ）を用いる場合は、Ｆｌａｓｈの消去・書込み中に更新が中断しても、途中から再開することができる。ただし、マイコン１３１の仕様によっては、Ｄａｔａエリア１３１３ａへのアクセスには時間がかかり、更新時間が長くなってしまう場合がある。また、マイコン１３１の仕様によっては、ソフトウェアの空きエリアは書換え可能な回数が少ない場合がある。また、ＳＲＡＭ１３１２を復元領域として利用する場合は、Ｆｌａｓｈ書き込み処理Ｓ４１１時に中断した場合は差分リジュームによるリカバリ処理は行えない。復元されたバージョン３の制御プログラムＰ２２は、図８のＦｌａｓｈ書き込み処理Ｓ４１１において、更新制御部１３００１がＦＲＯＭ制御部１３００４を介し、ＦＲＯＭ１３１３の該当領域に上書きする。図９（ａ）では、更新制御部１３００１、およびＦＲＯＭ制御部１３００４は図示していない。

　以上のように、受信したデータを逐次復元することで、バージョン３の制御プログラムＰ２２を再構成するために必要なすべての差分データを蓄積しなくても、差分更新を行うことができる。
　ただし、差分データが十分小さくメモリの余剰領域に格納できる場合は、必ずしも本手順に従い逐次復元する必要はなく、すべてのデータを受信後に復元処理を開始してもよい。しかしながらいずれの場合においても、実行中の制御プログラムを上書きする必要があるため、更新が中断した場合、制御プログラムは正常に動作しなくなる。

　図９（ｂ）は、メモリが多いＥＣＵにおける復元処理Ｓ４０７の処理を示す概念図である。差分／圧縮復元部１３００２は、更新制御部１３００１から復元指示を受けると、ゲートウェイ１０から受信し、ＳＲＡＭ１３１２に格納された更新データの一部５０１３ｂを読み出す。圧縮更新の場合は、更新データは圧縮されたソフトウェアであるため、これを伸長し復元領域Ｄ１００にバージョン３の制御プログラムＰ５２として出力する。本実施の形態では、復元領域Ｄ１００は、ＳＲＡＭ１３１２に確保している。差分更新の場合は、更新データは差分データであるため、差分／圧縮復元部１３００２は復元のために必要な現行の制御プログラムＰ４の一部または全部を読み出しこれらを組み合わせてバージョン３の制御プログラムＰ５２を復元し、復元領域Ｄ１００に出力する。復元された新ソフトウェアＰ５２は、図８のＦｌａｓｈ書き込み処理Ｓ４１１において、更新制御部１３００１がＦＲＯＭ制御部１３００４を介し、ＦＲＯＭ１３１３の該当領域に上書きする。ここでは、バージョン３の制御プログラムＰ５２は、ＢＡＮＫ１のバージョン１の制御プログラムＰ５１を上書きする。また、ここでは、更新制御部１３００１、ＦＲＯＭ制御部１３００４は図示していない。
　以上のように、２つ分の制御プログラムを格納するメモリを備えたＥＣＵの更新を行う場合は、制御プログラムの格納領域を２重化し、現在実行している制御プログラムを格納している領域とは別の領域に制御プログラムを復元・格納することで、更新が中断した場合も、実行中の制御プログラムを破損せず、正常動作を継続することができる。

　図１０は、ＥＣＵの起動シーケンス例である。
　図１０（ａ）は、メモリの少ないＥＣＵの起動シーケンス図である。
　メモリの少ないＥＣＵでは、最初にブートローダＰ１が起動される（Ｓ６０１）。ブートローダＰ１は、プログラムエリアに格納されている制御プログラムＰ２を検証する（Ｓ６０２）。検証の結果、制御プログラムＰ２に問題がないと判断されると（Ｓ６０３：ＹＥＳ）制御プログラムＰ２が起動される（Ｓ６０４）。また、検証の結果、制御プログラムＰ２に問題があると判断すると、制御プログラムＰ２を実行せずに緊急モードとしてゲートウェイ１０からの制御指示を待つ（Ｓ６０５）。この時、緊急モード特有の設定としてＩＳＯ１５７６５－２で規定される転送パラメータであるＢｌｏｃｋ　Ｓｉｚｅを０に設定し、ＣＡＮフレームのバースト転送を実施してもよい。これにより、通信の効率化を図ることができる。なお制御プログラムＰ２に問題があると判断する場合とは、たとえばソフトウェアが存在しない場合や、検証結果が異常な場合である。

　図１０（ｂ）は、メモリの多いＥＣＵの起動シーケンス図である。
　メモリの多いＥＣＵでは、最初にブートローダＰ３が起動される（Ｓ６５１）。ブートローダＰ３はＤａｔａエリア１３１３ｂＤ０のパラメータＤ３内の起動情報Ｄ３３を読み出し（Ｓ６５２）、起動情報Ｄ３３に記録された制御プログラムを実行する（Ｓ６５３）。たとえば起動情報Ｄ３３が「プログラムエリア１３１３ｂＰ０」である場合は、プログラムエリア１３１３ｂＰ０上のバージョン２の制御プログラムＰ４を実行する。

　図１１は、ゲートウェイ１０が起動時に行うリカバリ制御処理を示すフローチャートである。
　ゲートウェイ１０のリカバリ制御部１０００４は、ゲートウェイ１０が起動すると更新状態管理部１０００３を介して更新状態Ｄ１に記録された更新開始状態Ｄ１０２を取得する（Ｓ７０１）。リカバリ制御部１０００４は、更新が開始済みのＥＣＵが存在しない、すなわち、中断した更新がないと判断する場合（Ｓ７０２：ＮＯ）は、通常のゲートウェイ１０の起動処理を行う（Ｓ７１３）。

　更新が開始済みのＥＣＵが存在する、すなわち、中断した更新があると判断する場合（Ｓ７０２：ＹＥＳ）は、リカバリ制御部１０００４は、サーバ２に中断した更新がある旨を通知する（Ｓ７０３）。そしてリカバリ制御部１０００４は、リカバリ制御情報管理部１０００５を介して、当該ＥＣＵ　ＩＤに対応するＥＣＵリカバリ制御情報５０２１から、開始タイミング５０２１２を取得する（Ｓ７０４）。
　開始タイミング５０２１２が「即時」であると判断する場合（Ｓ７０５：ＹＥＳ）は、リカバリ制御情報５０２１の表示内容５０２１３に従って、ＨＭＩ１２に「緊急」の画面表示の指令を出力し（Ｓ７０６）、リカバリ処理を開始する（Ｓ７０７）。ただしこの場合はリカバリ処理を一刻も早く開始するために、ＨＭＩ１２への指令はリカバリ処理を開始してからでもよいし、２つの処理を同時に実行してもよい。リカバリ処理Ｓ７０７の詳細は後述する。

　開始タイミング５０２１２が「即時」以外の場合は、リカバリ制御情報５０２１の表示内容５０２１３を取得し（Ｓ７０８）、表示内容が「注意喚起」であると判断する場合は、ＨＭＩ１２に「注意喚起」の画面表示要求を行う（Ｓ７１０）。
　一方、表示内容が「警告」であると判断する場合は、ＨＭＩ１２に「警告」の画面表示要求を行う（Ｓ７１１）。画面表示要求送信後は、走行開始やＩＧＮ－ＯＦＦ等の更新開始トリガを待つ（Ｓ７１２）。その後、更新開始のトリガイベント発生を検出したら、リカバリ処理を開始する（Ｓ７０７）。リカバリ処理Ｓ７０７が完了すると、通常起動処理を行う（Ｓ７１３）。

　図１２は、第１の実施の形態におけるリカバリ処理Ｓ７０７の一例を示すフローチャートである。
　ゲートウェイ１０のリカバリ制御部１０００４は、リカバリ制御情報管理部１０００５を介して、当該ＥＣＵ　ＩＤに対応するリカバリ制御情報５０２１から、リカバリ方式５０２１４を取得し（Ｓ７０７０１）、ステップＳ７０７０２に進む。
　リカバリ方式５０２１４が「差分リジューム」であると判断する場合（Ｓ７０７０２：ＹＥＳ）、リカバリ制御部１０００４は、更新状態管理部１０００３を介して更新状態Ｄ１に記録された処理中ブロックを取得し（Ｓ７０７０３）、ＥＣＵとの間で当該ブロックから差分更新処理を再開する（Ｓ７０７０４）。

　リカバリ方式５０２１４が「差分リジューム」ではないと判断する場合（Ｓ７０７０２：ＮＯ）、リカバリ制御部１０００４はリカバリ方式５０２１４が「サーバ連携」であるか否かを判断する。リカバリ方式５０２１４が「サーバ連携」であると判断する場合（Ｓ７０７０５：ＹＥＳ）、リカバリ制御部１０００４は、リカバリ制御情報管理部１０００５を介して、当該ＥＣＵ　ＩＤに対応するリカバリ制御情報５０２１からリカバリデータＵＲＩ５０２１５を取得し（Ｓ７０７０６）、当該ＵＲＩからリカバリデータとして圧縮データを取得する（Ｓ７０７０７）。

　リカバリ方式５０２１４が「サーバ連携」ではないと判断する場合（Ｓ７０７０５：ＮＯ）、リカバリ制御部１０００４は、リカバリ方式５０２１４が「圧縮リカバリ」であるか否かを判断する。リカバリ方式５０２１４が「圧縮リカバリ」であると判断する場合（Ｓ７０７０９：ＹＥＳ）、リカバリ制御部１０００４は、リカバリ制御情報管理部１０００５を介して、当該ＥＣＵ　ＩＤに対応するＥＣＵリカバリデータ５０２２から圧縮データを取得する（Ｓ７０７１０）。
　リカバリ制御部１０００４は、ステップＳ７０７０７またはＳ７０７１０で圧縮データを取得後、取得した圧縮データを用いてＥＣＵとの間でリカバリ処理を実施する（Ｓ７０７０８）。

　リカバリ方式５０２１４が「圧縮リカバリ」ではないと判断する場合（Ｓ７０７０９：ＮＯ）、リカバリ制御部１０００４は、リカバリ制御情報管理部１０００５を介して、当該ＥＣＵ　ＩＤに対応するＥＣＵリカバリデータ５０２２からブロックＸＯＲデータを取得し（Ｓ７０７１１）、ＥＣＵとの間でブロックリカバリによるリカバリ処理を実施する（Ｓ７０７１２）。
　このように、サーバ２から更新制御情報５０１と共に更新パッケージ５として送信されるリカバリ制御情報５０２に基づいて更新異常発生時のリカバリ制御処理を実行することで、リソースや特性の異なる多数のＥＣＵからなるシステムで更新異常が発生した場合も、車両システムへの影響に応じて、適切なタイミングでリカバリを開始し、更新中断によるシステムへの影響をユーザに的確に伝達し、更新対象のＥＣＵの特性に応じたリカバリシーケンスでリカバリ処理を実行して、ソフトウェアを正常に更新することができる。

　（動作例）
　以下、図１３～図２４を用いて、自動運転ＥＣＵ１５、ＡＤＡＳ　ＥＣＵ１６、エンジン制御ＥＣＵ１３、ブレーキ制御ＥＣＵ１４、ＨＶＡＣ　ＥＣＵ１８、エアバッグＥＣＵ１７のリカバリ処理の動作例を説明する。

　（動作例―自動運転ＥＣＵ）
　図１３および図１４を用いて、自動運転ＥＣＵ１５に対応する更新パッケージ５ａの構成、ＨＭＩ１２への表示例、および動作シーケンスを説明する。
　図１３（ａ）は更新対象が自動運転ＥＣＵ１５のみの場合の更新パッケージ５ａの構成を示す図、図１３（ｂ）はその更新パッケージ５ａに含まれる自動運転ＥＣＵリカバリ制御情報５０２１ａの構成を示す図、図１３（ｃ）は自動運転ＥＣＵリカバリ制御情報５０２１ａに基づくＨＭＩ１２の表示例を示す図である。

　更新対象が自動運転ＥＣＵ１５のみの場合の更新パッケージ５ａは、図１３（ａ）に示すように、共通更新制御情報５０１１、自動運転ＥＣＵ更新制御情報５０１２ａ、自動運転ＥＣＵ更新データ５０１３ａを含む更新制御情報５０１ａと、自動運転ＥＣＵリカバリ制御情報５０２１ａを含むリカバリ制御情報５０２ａと、から構成される。
　自動運転ＥＣＵリカバリ制御情報５０２１ａは、図１３（ｂ）に示すように、ＥＣＵ　ＩＤ５０２１１ａには「自動運転ＥＣＵ」が設定され、開始タイミング５０２１２ａには「走行開始」が設定され、表示内容５０２１３ａには「注意喚起」および不図示の表示メッセージ情報が設定され、リカバリ方式５０２１４ａには「差分リジューム」が設定され、リカバリデータＵＲＩ５０２１５ａには情報が設定されていないことを意味する「ＮＵＬＬ」が設定される。

　リカバリ制御部１０００４は、表示内容５０２１３ａに基づきＨＭＩ１２の表示装置に図１３（ｃ）に示す画面表示Ｇ１０ａを出力させる。この画面表示Ｇ１０ａは、ソフトウェアの更新が中断されており、リカバリ処理による車両１の機能制限状態として更新後の機能がまだ使えない旨をユーザに告知するとともに、中断された更新については自動で適用されることを示す注意喚起である。

　図１４は、自動運転ＥＣＵ１５のリカバリ処理の１例を示すシーケンス図である。たとえば、自動運転ＥＣＵ１５の更新処理がゲートウェイ１０への電源供給断などにより中断され、電源供給が再開されると、以下のようにリカバリ処理が実行される。なお自動運転ＥＣＵ１５は、メモリが多いＥＣＵに分類され、図５（ｂ）に示すように２つの制御プログラムを格納できる。
　ゲートウェイ１０は起動すると図１１に示した処理を開始する。すなわち、最初に、ステップＳ９０１ａにおいて中断中の更新の有無を確認する（図１１のＳ７０１、Ｓ７０２、図１４のＳ９０１ａ）。

　また、ゲートウェイ１０の処理と並行して、自動運転ＥＣＵ１５では、図１０（ｂ）に示した起動処理を行う。ここでは、更新が中断し、起動情報Ｄ３３はまだ書き換わっておらずプログラムエリア１３１３ｂＰ０に記録された制御プログラムの起動が指定されているため、自動運転ＥＣＵ１５は現行のバージョン２の制御プログラムＰ４を起動する。
　ゲートウェイ１０は、更新状態Ｄ２１の更新開始状態Ｄ１０２から自動運転ＥＣＵ１５の更新が中断していると判定すると（Ｓ９０１ａ）、ステップＳ９０３ａにおいて以下の処理を行う。すなわちゲートウェイ１０は、自動運転ＥＣＵ１５に該当する自動運転ＥＣＵリカバリ制御情報５０２１ａから開始タイミング５０２１２ａを読み出し、自動運転ＥＣＵ１５のリカバリ処理を開始するタイミングが、走行開始後であると判定する。

　次にゲートウェイ１０は、ステップＳ９０４ａにおいて自動運転ＥＣＵリカバリ制御情報５０２１ａから表示内容５０２１３ａを読み出し、表示内容５０２１３ａに基づく注意喚起画面を表示する要求をＨＭＩ１２に発行する。ＨＭＩ１２は、この要求に基づき図１３（ｃ）のＧ１０ａに例示する注意喚起画面を表示装置に表示する（Ｓ９０５ａ）。ゲートウェイ１０は、ステップＳ９０６ａにおいてリカバリ処理を開始するトリガである走行開始を検出すると、自動運転ＥＣＵリカバリ制御情報５０２１ａのリカバリ方式５０２１４ａを読み出し、リカバリ処理の方式が「差分リジューム」であると判定する（Ｓ９０７ａ）。前述のとおり「差分リジューム」によるリカバリとは、差分更新が中断した場合、中断したブロックから差分更新を再開することで、短時間で更新を完了できるようにする方式のことである。ゲートウェイ１０は、リジュームを開始するポイントを決定するために、更新状態Ｄ２１の処理中ブロックＤ１０３を読み出す（Ｓ９０８ａ）。ゲートウェイ１０は、リジュームを開始するブロックを決定した後、ステップ９０９ａにおいて、当該ブロックから図８のソフトウェア更新処理Ｓ４を実施し、自動運転ＥＣＵ１５の更新を完了する。

　自動運転ＥＣＵ１５のように豊富なメモリを備え、制御プログラムが２重化できる場合は、現在実行している制御プログラムを格納している領域とは別の領域に更新後の制御プログラムを復元または格納することができるので以下の利点がある。すなわち、更新が中断した場合も実行中の制御プログラムを破損せず、再起動時に実行中の制御プログラムを起動することで正常な動作を維持することができる。このため、上記のとおりリカバリ制御情報５０２ａを構成し、これを用いることで、ゲートウェイ１０は、自動運転ＥＣＵ１５の更新が中断された場合でも即時に更新を完了させなくてもよく、次の走行時に更新を再開すればよい。
　ゲートウェイ１０は、更新が中断した旨と中断した更新の再開は走行中に自動的に行われる旨を、ＨＭＩ１２に注意喚起画面を表示させることでユーザに伝達する。また更新状態Ｄ１に更新状態が記録されているので、中断ポイントからリカバリの実行を開始、すなわち更新を再開し、迅速に更新を完了することができる。
　なお前述の例では、自動運転ＥＣＵ１５の更新が中断した際に、注意喚起画面を表示させる例を示した。しかし、例えば自動運転ＥＣＵ１５の更新が走行中などに完全にバックグラウンドで実施されユーザが意識しない間に完了させる場合、注意喚起画面を表示させないように制御してもよい。この場合、図１３の表示内容５０２１３ａには、「注意喚起」ではなく「画面表示なし」が設定される。

　（動作例―ＡＤＡＳ　ＥＣＵ）
　図１５および図１６を用いて、ＡＤＡＳ　ＥＣＵ１６に対応する更新パッケージ５ｂの構成、ＨＭＩ１２への表示例、および動作シーケンスを説明する。
　図１５（ａ）は更新対象がＡＤＡＳ　ＥＣＵ１６のみの場合の更新パッケージ５ｂの構成を示す図、図１５（ｂ）はその更新パッケージ５ｂに含まれるＡＤＡＳ　ＥＣＵリカバリ制御情報５０２１ｂの構成を示す図、図１５（ｃ）はＡＤＡＳ　ＥＣＵリカバリ制御情報５０２１ｂに基づくＨＭＩ１２の表示例を示す図である。

　更新対象がＡＤＡＳ　ＥＣＵ１６のみの場合の更新パッケージ５ｂは、図１５（ａ）に示すように、共通更新制御情報５０１１、ＡＤＡＳ　ＥＣＵ更新制御情報５０１２ｂ、ＡＤＡＳ　ＥＣＵ更新データ５０１３ｂを含む更新制御情報５０１ｂと、ＡＤＡＳ　ＥＣＵリカバリ制御情報５０２１ｂを含むリカバリ制御情報５０２ｂと、から構成される。
　ＡＤＡＳ　ＥＣＵリカバリ制御情報５０２１ｂは、図１５（ｂ）に示すように、ＥＣＵ　ＩＤ５０２１１ｂには「ＡＤＡＳ　ＥＣＵ」が設定され、開始タイミング５０２１２ｂには「ＩＧＮ－ＯＦＦ」が設定され、表示内容５０２１３ｂには「注意喚起」および不図示の表示メッセージ情報が設定され、リカバリ方式５０２１４ｂには「差分リジューム」が設定され、リカバリデータＵＲＩ５０２１５ｂには情報が設定されていないことを意味する「ＮＵＬＬ」が設定される。

　リカバリ制御部１０００４は、表示内容５０２１３ｂに基づきＨＭＩ１２の表示装置に図１５（ｃ）に示す画面表示Ｇ１０ｂを出力させる。この画面表示Ｇ１０ｂは、ソフトウェアの更新が中断されており、リカバリ処理による車両１の機能制限状態として更新後の機能がまだ使えない旨をユーザに告知するとともに、中断された更新については次にＩＧＮ－ＯＦＦ、すなわちイグニッションがオフにされたタイミングで適用されることを示す注意喚起である。

　図１６は、ＡＤＡＳ　ＥＣＵ１６のリカバリ処理の１例を示すシーケンス図である。たとえば、ＡＤＡＳ　ＥＣＵ１６の更新処理がゲートウェイ１０への電源供給断などにより中断され、電源供給が再開されると、以下のようにリカバリ処理が実行される。なおＡＤＡＳ　ＥＣＵ１６は、メモリが多いＥＣＵに分類され、図５（ｂ）に示すように２つの制御プログラムを格納できる。
　ゲートウェイ１０は起動すると図１１に示した処理を開始する。すなわち、最初に、ステップＳ９０１ｂにおいて中断中の更新の有無を確認する（図１１のＳ７０１、Ｓ７０２、図１６のＳ９０１ｂ）。

　また、ゲートウェイ１０の処理と並行して、ＡＤＡＳ　ＥＣＵ１６では、図１０（ｂ）に示した起動処理を行う。ここでは、更新が中断し、起動情報Ｄ３３はまだ書き換わっておらずプログラムエリア１３１３ｂＰ０に記録された制御プログラムの起動が指定されているため、ＡＤＡＳ　ＥＣＵ１６は現行のバージョン２の制御プログラムＰ４を起動する。
　ゲートウェイ１０は、更新状態Ｄ２１の更新開始状態Ｄ１０２からＡＤＡＳ　ＥＣＵ１６の更新が中断していると判定すると（Ｓ９０１ｂ）、ステップＳ９０３ｂにおいて以下の処理を行う。すなわちゲートウェイ１０は、ＡＤＡＳ　ＥＣＵ１６に該当するＡＤＡＳ　ＥＣＵリカバリ制御情報５０２１ｂから開始タイミング５０２１２ｂを読み出し、ＡＤＡＳ　ＥＣＵ１６のリカバリ処理を開始するタイミングが、ＩＧＮ－ＯＦＦであると判定する。

　次にゲートウェイ１０は、ステップＳ９０４ｂにおいてＡＤＡＳ　ＥＣＵリカバリ制御情報５０２１ｂから表示内容５０２１３ｂを読み出し、表示内容５０２１３ｂに基づく注意喚起画面を表示する要求をＨＭＩ１２に発行する。ＨＭＩ１２は、この要求に基づき図１５（ｃ）のＧ１０ｂに例示する注意喚起画面を表示装置に表示する（Ｓ９０５ｂ）。ゲートウェイ１０は、ステップＳ９０６ｂにおいてリカバリ処理を開始するトリガであるイグニッションＯＦＦ信号が車両１から入力されると、これを検出し（Ｓ９０７ｂ）、ＡＤＡＳ　ＥＣＵリカバリ制御情報５０２１ｂのリカバリ方式５０２１４ｂを読み出して、リカバリ処理の方式が「差分リジューム」であると判定する（Ｓ９０８ｂ）。前述のとおり「差分リジューム」によるリカバリとは、差分更新が中断した場合、中断したブロックから差分更新を再開することで、短時間で更新を完了できるようにする方式のことである。ゲートウェイ１０は、リジュームを開始するポイントを決定するために、更新状態Ｄ２１の処理中ブロックＤ１０３を読み出す（Ｓ９０９ｂ）。ゲートウェイ１０は、リジュームを開始するブロックを決定した後、ステップ９１０ｂにおいて、当該ブロックから図８のソフトウェア更新処理Ｓ４を実施し、ＡＤＡＳ　ＥＣＵ１６の更新を完了する。

　ＡＤＡＳ　ＥＣＵ１６も自動運転ＥＣＵ１５と同様に豊富なメモリを備えるので、自動運転ＥＣＵ１５と同様の利点がある。
　ゲートウェイ１０は、ユーザには更新が中断した旨と、中断した更新の再開はイグニッションオフにより行われる旨をＨＭＩ１２に注意喚起画面を表示させることでユーザに伝達する。また更新状態Ｄ１に更新状態が記録されているので、中断ポイントからリカバリの実行を開始、すなわち更新を再開し、迅速に更新を完了することができる。

　（動作例―エンジン制御ＥＣＵ）
　図１７および図１８を用いて、エンジン制御ＥＣＵ１３に対応する更新パッケージ５ｃの構成、ＨＭＩ１２への表示例、および動作シーケンスを説明する。
　図１７（ａ）は更新対象がエンジン制御ＥＣＵ１３のみの場合の更新パッケージ５ｃの構成を示す図、図１７（ｂ）はその更新パッケージ５ｃに含まれるエンジン制御ＥＣＵリカバリ制御情報５０２１ｃの構成を示す図、図１７（ｃ）はエンジン制御ＥＣＵリカバリ制御情報５０２１ｃに基づくＨＭＩ１２の表示例を示す図である。

　更新対象がエンジン制御ＥＣＵ１３のみの場合の更新パッケージ５ｃは、図１７（ａ）に示すように、共通更新制御情報５０１１、エンジン制御ＥＣＵ更新制御情報５０１２ｃ、エンジン制御ＥＣＵ更新データ５０１３ｃを含む更新制御情報５０１ｃと、エンジン制御ＥＣＵリカバリ制御情報５０２１ｃを含むリカバリ制御情報５０２ｃと、から構成される。
　エンジン制御ＥＣＵリカバリ制御情報５０２１ｃは、図１７（ｂ）に示すように、ＥＣＵ　ＩＤ５０２１１ｃには「エンジン制御ＥＣＵ」が設定され、開始タイミング５０２１２ｃには「即時」が設定され、表示内容５０２１３ｃには「緊急」および不図示の表示メッセージ情報が設定され、リカバリ方式５０２１４ｃには「差分リジューム」が設定され、リカバリデータＵＲＩ５０２１５ｃには情報が設定されていないことを意味する「ＮＵＬＬ」が設定される。

　リカバリ制御部１０００４は、表示内容５０２１３ｃに基づきＨＭＩ１２の表示装置に図１７（ｃ）に示す画面表示Ｇ１０ｃを出力させる。この画面表示Ｇ１０ｃは、ソフトウェアの更新が中断されており、リカバリ処理による車両１の機能制限状態として車両１が使えない旨をユーザに告知するとともに、中断された更新については即時リカバリ中であることを示す。

　図１８は、エンジン制御ＥＣＵ１３のリカバリ処理の１例を示すシーケンス図である。たとえば、エンジン制御ＥＣＵ１３の更新処理がゲートウェイ１０への電源供給断などにより中断され、電源供給が再開されると、以下のようにリカバリ処理が実行される。なおエンジン制御ＥＣＵ１３は、メモリが少ないＥＣＵに分類され、図５（ａ）に示すように制御プログラムは１つのみ格納できる。
　ゲートウェイ１０は起動すると図１１に示した処理を開始する。すなわち、最初に、ステップＳ９０１ｃにおいて中断中の更新の有無を確認する（図１１のＳ７０１、Ｓ７０２、図１８のＳ９０１ｃ）。

　また、ゲートウェイ１０の処理と並行して、エンジン制御ＥＣＵ１３では、図１０（ａ）に示した起動処理を行う。ここでは、更新が中断し、現行のバージョン２の制御プログラムの一部がバージョン３の制御プログラムの一部で上書きされてしまっている状態のため、制御プログラムＰ２の検証に問題が発生し、緊急モードで起動される（Ｓ９０２ｃ）。
　ゲートウェイ１０は、更新状態Ｄ２１の更新開始状態Ｄ１０２からエンジン制御ＥＣＵ１３の更新が中断していると判定すると（Ｓ９０１ｃ）、ステップＳ９０３ｃにおいて以下の処理を行う。すなわちゲートウェイ１０は、エンジン制御ＥＣＵ１３に該当するエンジン制御ＥＣＵリカバリ制御情報５０２１ｃから開始タイミング５０２１２ｃを読み出し、エンジン制御ＥＣＵ１３のリカバリ処理を開始するタイミングが即時であると判定する。

　次にゲートウェイ１０は、ステップＳ９０４ｃにおいてエンジン制御ＥＣＵリカバリ制御情報５０２１ｃから表示内容５０２１３ｃを読み出し、表示内容５０２１３ｃに基づく緊急画面を表示する要求をＨＭＩ１２に発行する。ＨＭＩ１２は、この要求に基づき図１７（ｃ）のＧ１０ｃに例示する緊急画面を表示装置に表示する（Ｓ９０５ｃ）。ゲートウェイ１０は、リカバリ処理を開始するタイミングが即時なので、ステップＳ９０４ｃでＨＭＩ１２に緊急画面の表示要求を発行すると即時にエンジン制御ＥＣＵリカバリ制御情報５０２１ｃのリカバリ方式５０２１４ｃを読み出し、リカバリ処理の方式が「差分リジューム」であると判定する（Ｓ９０６ｃ）。ゲートウェイ１０は、ステップＳ９０７ｃにおいてリジュームを開始するポイントを決定するために、更新状態Ｄ２１の処理中ブロックＤ１０３を読み出す。ゲートウェイ１０は、リジュームを開始するブロックを決定した後、ステップ９０８ｃにおいて、当該ブロックから図８のソフトウェア更新処理Ｓ４を実施し、エンジン制御ＥＣＵ１３の更新を完了する。

　エンジン制御ＥＣＵ１３のようなメモリが少ないＥＣＵの場合は、単一の制御プログラムを上書きしながら更新を行う必要があるため、更新が中断した場合は、制御プログラムは正常動作できなくなる。このため、エンジン制御ＥＣＵ１３の更新が中断した場合、エンジン制御が行えず、走行ができなくなってしまう。上記のとおりリカバリ制御情報５０２ｃを構成し、これを用いることで、ゲートウェイ１０はエンジン制御ＥＣＵ１３の更新が中断した際は、中断した更新の再開を即時に行う必要があると判断する。またゲートウェイ１０は、車両が使用できない旨と中断した更新の再開は即時開始されている旨をＨＭＩ１２に緊急画面を表示させることでユーザに伝達する。また更新状態Ｄ１に更新状態が記録されているので、中断ポイントからリカバリの実行を開始、すなわち更新を再開し、迅速に更新を完了することができる。

　（動作例―ブレーキ制御ＥＣＵ）
　図１９および図２０を用いて、ブレーキ制御ＥＣＵ１４に対応する更新パッケージ５ｄの構成、ＨＭＩ１２への表示例、および動作シーケンスを説明する。
　図１９（ａ）は更新対象がブレーキ制御ＥＣＵ１４のみの場合の更新パッケージ５ｄの構成を示す図、図１９（ｂ）はその更新パッケージ５ｄに含まれるブレーキ制御ＥＣＵリカバリ制御情報５０２１ｄの構成を示す図、図１９（ｃ）はブレーキ制御ＥＣＵリカバリ制御情報５０２１ｄに基づくＨＭＩ１２の表示例を示す図である。

　更新対象がブレーキ制御ＥＣＵ１４のみの場合の更新パッケージ５ｄは、図１９（ａ）に示すように、共通更新制御情報５０１１、ブレーキ制御ＥＣＵ更新制御情報５０１２ｄ、およびブレーキ制御ＥＣＵ更新データ５０１３ｄを含む更新制御情報５０１ｄと、ブレーキ制御ＥＣＵリカバリ制御情報５０２１ｄ、およびブレーキ制御ＥＣＵリカバリデータ５０２２ｄを含むリカバリ制御情報５０２ｄと、から構成される。
　ブレーキ制御ＥＣＵリカバリ制御情報５０２１ｄは、図１９（ｂ）に示すように、ＥＣＵ　ＩＤ５０２１１ｄには「ブレーキ制御ＥＣＵ」が設定され、開始タイミング５０２１２ｄには「即時」が設定され、表示内容５０２１３ｄには「緊急」および不図示の表示メッセージ情報が設定され、リカバリ方式５０２１４ｄには「圧縮リカバリ」が設定され、リカバリデータＵＲＩ５０２１５ｄには情報が設定されていないことを意味する「ＮＵＬＬ」が設定される。

　リカバリ制御部１０００４は、表示内容５０２１３ｄに基づきＨＭＩ１２の表示装置に図１９（ｃ）に示す画面表示Ｇ１０ｄを出力させる。この画面表示Ｇ１０ｄは、ソフトウェアの更新が中断されており、リカバリ処理による車両１の機能制限状態として車両１が使えない旨をユーザに告知するとともに、中断された更新については即時リカバリ中であることを示す。

　図２０は、ブレーキ制御ＥＣＵ１４のリカバリ処理の１例を示すシーケンス図である。たとえば、ブレーキ制御ＥＣＵ１４の更新処理がゲートウェイ１０への電源供給断などにより中断され、電源供給が再開されると、以下のようにリカバリ処理が実行される。なおブレーキ制御ＥＣＵ１４は、メモリが少ないＥＣＵに分類され、図５（ａ）に示すように制御プログラムは１つのみ格納できる。
　ゲートウェイ１０は起動すると図１１に示した処理を開始する。すなわち、最初に、ステップＳ９０１ｄにおいて中断中の更新の有無を確認する（図１１のＳ７０１、Ｓ７０２、図２０のＳ９０１ｄ）。

　また、ゲートウェイ１０の処理と並行して、ブレーキ制御ＥＣＵ１４では、図１０（ａ）に示した起動処理を行う。ここでは、更新が中断し、現行のバージョン２の制御プログラムの一部がバージョン３の制御プログラムの一部で上書きされてしまっている状態のため、制御プログラムＰ２の検証に問題が発生し、緊急モードで起動される（Ｓ９０２ｄ）。
　ゲートウェイ１０は、更新状態Ｄ２１の更新開始状態Ｄ１０２からブレーキ制御ＥＣＵ１４の更新が中断していると判定すると（Ｓ９０１ｄ）、ステップＳ９０３ｄにおいて以下の処理を行う。すなわちゲートウェイ１０は、ブレーキ制御ＥＣＵ１４に該当するブレーキ制御ＥＣＵリカバリ制御情報５０２１ｄから開始タイミング５０２１２ｄを読み出し、ブレーキ制御ＥＣＵ１４のリカバリ処理を開始するタイミングが即時であると判定する。

　次にゲートウェイ１０は、ステップＳ９０４ｄにおいてブレーキ制御ＥＣＵリカバリ制御情報５０２１ｄから表示内容５０２１３ｄを読み出し、表示内容５０２１３ｄに基づく緊急画面を表示する要求をＨＭＩ１２に発行する。ＨＭＩ１２は、この要求に基づき図１９（ｃ）のＧ１０ｄに例示する緊急画面を表示装置に表示する（Ｓ９０５ｃ）。ゲートウェイ１０は、リカバリ処理を開始するタイミングが即時なので、ステップＳ９０４ｄでＨＭＩ１２に緊急画面の表示要求を発行すると即時にブレーキ制御ＥＣＵリカバリ制御情報５０２１ｄのリカバリ方式５０２１４ｄを読み出し、リカバリ処理の方式が「圧縮リカバリ」であると判定する（Ｓ９０６ｄ）。前述のとおり「圧縮リカバリ」方式によるリカバリとは、ソフトウェアの圧縮データを用いて、ソフトウェアの全領域の書込みまたは、破損した領域の書込み、すなわち修復を行うことで、確実にリカバリを行う方式である。ゲートウェイ１０は、ステップＳ９０７ｄにおいて、更新パッケージ５ｄに同梱されたバージョン３の制御プログラムの圧縮データであるブレーキ制御ＥＣＵリカバリデータ５０２２ｄを読み出す。そしてゲートウェイ１０は、読みだしたブレーキ制御ＥＣＵリカバリデータ５０２２ｄを用いて図８のソフトウェア更新処理Ｓ４を実施し、ブレーキ制御ＥＣＵ１４の更新を完了する。

　ブレーキ制御ＥＣＵ１４もエンジン制御ＥＣＵ１３と同様にメモリが少ないので、上記のとおりリカバリ制御情報５０２ｃを構成し、これを用いることで、ゲートウェイ１０はブレーキ制御ＥＣＵ１４の更新が中断した際は、中断した更新の再開を即時に行う必要があると判断する。またゲートウェイ１０は、車両が使用できない旨と中断した更新の再開は即時開始されている旨をＨＭＩ１２に緊急画面を表示させることでユーザに伝達する。さらに、ブレーキ制御ＥＣＵリカバリデータ５０２２ｄとしてバージョン３の制御プログラムを圧縮したデータを同梱して制御プログラムの修復を行うようにすることで、差分リジュームの以下の問題点を回避できる。すなわち差分リジュームでは、復元領域としてＤａｔａエリア１３１３ａを用いることで処理時間が長くなってしまう問題点や、書換え回数の少ない可能性のあるプログラムエリアを使用してしまう問題点があるが、圧縮リカバリ方式ではこれらの問題点を回避できる。また、後述のブロックリカバリでは、ＥＣＵのソフトウェア修復中に再度中断した場合は、その後の復元ができなくなるが、圧縮データによる修復の場合は、再度中断した場合も対応が可能となる。

　（動作例―ＨＶＡＣ　ＥＣＵ）
　図２１および図２２を用いて、ＨＶＡＣ　ＥＣＵ１８に対応する更新パッケージ５ｅの構成、ＨＭＩ１２への表示例、および動作シーケンスを説明する。
　図２１（ａ）は更新対象がＨＶＡＣ　ＥＣＵ１８のみの場合の更新パッケージ５ｅの構成を示す図、図２１（ｂ）はその更新パッケージ５ｅに含まれるＨＶＡＣ　ＥＣＵリカバリ制御情報５０２１ｅの構成を示す図、図２１（ｃ）はＨＶＡＣ　ＥＣＵリカバリ制御情報５０２１ｅに基づくＨＭＩ１２の表示例を示す図である。

　更新対象がＨＶＡＣ　ＥＣＵ１８のみの場合の更新パッケージ５ｅは、図２１（ａ）に示すように、共通更新制御情報５０１１、ＨＶＡＣ　ＥＣＵ更新制御情報５０１２ｅ、ＨＶＡＣ　ＥＣＵ更新データ５０１３ｅを含む更新制御情報５０１ｅと、ＨＶＡＣ　ＥＣＵリカバリ制御情報５０２１ｅを含むリカバリ制御情報５０２ｅと、から構成される。
　ＨＶＡＣ　ＥＣＵリカバリ制御情報５０２１ｅは、図２１（ｂ）に示すように、ＥＣＵ　ＩＤ５０２１１ｅには「ＨＶＡＣ　ＥＣＵ」が設定され、開始タイミング５０２１２ｅには「ＩＧＮ－ＯＦＦ」が設定され、表示内容５０２１３ｅには「警告」および不図示の表示メッセージ情報が設定され、リカバリ方式５０２１４ｅには「サーバ連携」が設定され、リカバリデータＵＲＩ５０２１５ｅにはリカバリデータが格納されているＵＲＩである「htttps://example.jp/data」が設定される。

　リカバリ制御部１０００４は、表示内容５０２１３ｅに基づきＨＭＩ１２の表示装置に図２１（ｃ）に示す画面表示Ｇ１０ｅを出力させる。この画面表示Ｇ１０ｅは、ソフトウェアの更新が中断されており、リカバリ処理による車両１の機能制限状態としてＨＶＡＣ機能が使えない旨をユーザに告知するとともに、リカバリのためにはサーバ２との通信が必要であることを示す警告である。

　図２２は、ＨＶＡＣ　ＥＣＵ１８のリカバリ処理の１例を示すシーケンス図である。たとえば、ＨＶＡＣ　ＥＣＵ１８の更新処理がゲートウェイ１０への電源供給断などにより中断され、電源供給が再開されると、以下のようにリカバリ処理が実行される。なおＨＶＡＣ　ＥＣＵ１８は、メモリが少ないＥＣＵに分類され、図５（ａ）に示すように制御プログラムは１つのみ格納できる。
　ゲートウェイ１０は起動すると図１１に示した処理を開始する。すなわち、最初に、ステップＳ９０１ｅにおいて中断中の更新の有無を確認する（図１１のＳ７０１、Ｓ７０２、図２２のＳ９０１ｅ）。

　また、ゲートウェイ１０の処理と並行して、ＨＶＡＣ　ＥＣＵ１８では、図１０（ａ）に示した起動処理を行う。ここでは、更新が中断し、現行のバージョン２の制御プログラムの一部がバージョン３の制御プログラムの一部で上書きされてしまっている状態のため、制御プログラムＰ２の検証に問題が発生し、緊急モードで起動される（Ｓ９０２ｅ）。
　ゲートウェイ１０は、更新状態Ｄ２１の更新開始状態Ｄ１０２からＨＶＡＣ　ＥＣＵ１８の更新が中断していると判定すると（Ｓ９０１ｅ）、ステップＳ９０３ｅにおいて以下の処理を行う。すなわちゲートウェイ１０は、ＨＶＡＣ　ＥＣＵ１８に該当するＨＶＡＣ　ＥＣＵリカバリ制御情報５０２１ｅから開始タイミング５０２１２ｅを読み出し、ＨＶＡＣ　ＥＣＵ１８のリカバリ処理を開始するタイミングがイグニッションＯＦＦであると判断する。

　次にゲートウェイ１０は、ステップＳ９０４ｅにおいてＨＶＡＣ　ＥＣＵリカバリ制御情報５０２１ｅから表示内容５０２１３ｅを読み出し、表示内容５０２１３ｅに基づく警告画面を表示する要求をＨＭＩ１２に発行する。ＨＭＩ１２は、この要求に基づき図２１（ｃ）のＧ１０ｅに例示する警告画面を表示する（Ｓ９０５ｅ）。

　ゲートウェイ１０は、イグニッションＯＦＦ信号を受信すると（ステップＳ９０６ｅ）これを検出する（Ｓ９０７ｅ）。そしてＨＶＡＣ　ＥＣＵリカバリ制御情報５０２１ｅのリカバリ方式５０２１４ｅを読み出し、リカバリ処理の方式が「サーバ連携」であると判定する（Ｓ９０８ｅ）。前述のとおり「サーバ連携」方式によるリカバリとは、中断した更新を完了またはロールバックさせるために必要なデータを、リカバリ時にサーバ２から取得する方式である。通信モジュール１１がサーバ２との通信が有効化されたことを検出すると、ゲートウェイ１０は通信モジュール１１からこの通知を受ける（Ｓ９０９ｅ）。そしてゲートウェイ１０は、通信モジュール１１を経由してサーバ２のリカバリデータＵＲＩ５０２１５ｄに対してリカバリデータ取得要求を送信し（ステップ９１０ｅ）、リカバリデータを受信する（Ｓ９１１ｅ）。さらにゲートウェイ１０は、受信したリカバリデータを用いて更新処理を実施し（Ｓ９１２ｅ）、ＨＶＡＣ　ＥＣＵ１８の更新を完了する。

　ＨＶＡＣ　ＥＣＵ１８もエンジン制御ＥＣＵ１３やブレーキ制御ＥＣＵ１４と同様にメモリが少なく、単一の制御プログラムを上書きしながら更新を行う必要があるため、更新が中断した場合は、制御プログラムは正常動作できなくなる。このため、ＨＶＡＣ　ＥＣＵ１８の更新が中断した場合、ＨＶＡＣ制御が行えないが、車両１の走行への影響は少ない。上記のとおりリカバリ制御情報５０２ｅを構成し、これを用いてゲートウェイ１０はＨＶＡＣ　ＥＣＵ１８の更新が中断した際は、すぐにＨＶＡＣ　ＥＣＵ１８を制御して更新を完了させなくてもよく、サーバ連携によりサーバ２から必要なデータをダウンロードした後、次のイグニッションＯＦＦ時に更新を再開する。またゲートウェイ１０は、更新が中断したためＨＶＡＣ機能が使えない旨、更新の再開のためには通信可能な環境に移動することが必要である旨、さらに中断した更新の再開はイグニッションＯＦＦ時に開始できる旨を、ＨＭＩ１２に警告画面を表示させることでユーザに伝達する。

　またゲートウェイ１０は、リカバリ処理に用いるデータをリカバリデータＵＲＩ５０２１５に記載されたＵＲＩから取得することができる。さらに、頻度の少ない異常発生時のみ、サーバから必要なリカバリデータを取得してＥＣＵのソフトウェアを修復する構成とすることで、ゲートウェイ１０やＥＣＵにリカバリデータやバックアップデータを格納するための追加メモリを準備する必要がなくなり、低コストにシステムを構築できる。

　（動作例―エアバッグＥＣＵ）
　図２３および図２４を用いて、エアバッグＥＣＵ１７に対応する更新パッケージ５ｆの構成、ＨＭＩ１２への表示例、および動作シーケンスを説明する。
　図２３（ａ）は更新対象がエアバッグＥＣＵ１７のみの場合の更新パッケージ５ｆの構成を示す図、図２３（ｂ）はその更新パッケージ５ｆに含まれるエアバッグＥＣＵリカバリ制御情報５０２１ｆの構成を示す図、図２３（ｃ）はエアバッグＥＣＵリカバリ制御情報５０２１ｆに基づくＨＭＩ１２の表示例を示す図である。

　更新対象がエアバッグＥＣＵ１７のみの場合の更新パッケージ５ｆは、図２３（ａ）に示すように、共通更新制御情報５０１１、エアバッグＥＣＵ更新制御情報５０１２ｆ、エアバッグＥＣＵ更新データ５０１３ｆを含む更新制御情報５０１ｆと、エアバッグＥＣＵリカバリ制御情報５０２１ｆ、およびエアバッグＥＣＵリカバリデータ５０２２ｆを含むリカバリ制御情報５０２ｆと、から構成される。
　エアバッグＥＣＵリカバリ制御情報５０２１ｆは、図２３（ｂ）に示すように、ＥＣＵ　ＩＤ５０２１１ｆには「エアバッグＥＣＵ」が設定され、開始タイミング５０２１２ｆには「ＩＧＮ－ＯＦＦ」が設定され、表示内容５０２１３ｆには「警告」および不図示の表示メッセージ情報が設定され、リカバリ方式５０２１４ｆには「ブロックリカバリ」が設定され、リカバリデータＵＲＩ５０２１５ｆには情報が設定されていないことを意味する「ＮＵＬＬ」が設定される。

　リカバリ制御部１０００４は、表示内容５０２１３ｆに基づきＨＭＩ１２の表示装置に図２３（ｃ）に示す画面表示Ｇ１０ｆを出力させる。この画面表示Ｇ１０ｆは、ソフトウェアの更新が中断されており、リカバリ処理による車両１の機能制限状態としてエアバッグが使えない旨をユーザに告知するとともに、中断された更新を再開するタイミングは次のイグニッションＯＦＦのタイミングであることを示す。

　図２４は、エアバッグＥＣＵ１７のリカバリ処理の１例を示すシーケンス図である。たとえば、エアバッグＥＣＵ１７の更新処理がゲートウェイ１０への電源供給断などにより中断され、電源供給が再開されると、以下のようにリカバリ処理が実行される。なおエアバッグＥＣＵ１７は、メモリが少ないＥＣＵに分類され、図５（ａ）に示すように制御プログラムは１つのみ格納できる。
　ゲートウェイ１０は起動すると図１１に示した処理を開始する。すなわち、最初に、ステップＳ９０１ｆにおいて中断中の更新の有無を確認する（図１１のＳ７０１、Ｓ７０２、図２４のＳ９０１ｆ）。

　また、ゲートウェイ１０の処理と並行して、エアバッグＥＣＵ１７では、図１０（ａ）に示した起動処理を行う。ここでは、更新が中断し、現行のバージョン２の制御プログラムの一部がバージョン３の制御プログラムの一部で上書きされてしまっている状態のため、制御プログラムＰ２の検証に問題が発生し、緊急モードで起動される（Ｓ９０２ｆ）。
　ゲートウェイ１０は、更新状態Ｄ２１の更新開始状態Ｄ１０２からエアバッグＥＣＵ１７の更新が中断していると判定すると（Ｓ９０１ｆ）、ステップＳ９０３ｆにおいて以下の処理を行う。すなわちゲートウェイ１０は、エアバッグＥＣＵ１７に該当するエアバッグＥＣＵリカバリ制御情報５０２１ｆから開始タイミング５０２１２ｆを読み出し、エアバッグＥＣＵ１７のリカバリ処理を開始するタイミングがイグニッションＯＦＦであると判定する。

　次にゲートウェイ１０は、ステップＳ９０４ｆにおいてエアバッグＥＣＵリカバリ制御情報５０２１ｆから表示内容５０２１３ｆを読み出し、表示内容５０２１３ｆに基づく警告画面を表示する要求をＨＭＩ１２に発行する。ＨＭＩ１２は、この要求に基づき図２３（ｃ）のＧ１０ｆに例示する警告画面を表示する（Ｓ９０５ｆ）。ゲートウェイ１０は、リカバリ処理を開始するトリガであるイグニッションＯＦＦ信号を受信すると（Ｓ９０６ｆ）これを検出する（Ｓ９０７ｆ）。そしてゲートウェイ１０は、エアバッグＥＣＵリカバリ制御情報５０２１ｆのリカバリ方式５０２１４ｆを読み出し、リカバリ処理の方式が「ブロックリカバリ」であると判定し（Ｓ９０８ｆ）、更新パッケージ５ｆに同梱されたエアバッグＥＣＵリカバリデータ５０２２ｆを読み出す（Ｓ９０９ｆ）。

　ゲートウェイ１０は、ステップＳ９１０ｆにおいてリジュームを開始するポイントを決定するために、更新状態Ｄ２１の処理中ブロックＤ１０３を読み出す。ゲートウェイ１０は、リジュームを開始するブロックを決定した後、ステップ９１１ｆにおいて、当該ブロックの次のブロックから図８のソフトウェア更新処理Ｓ４を実施し、中断したブロック以外のエアバッグＥＣＵ１７の更新を完了する。ゲートウェイ１０は、ステップＳ９１２ｆにおいて、ステップＳ９０９ｆで取得したリカバリデータをエアバッグＥＣＵ１７に送信する。エアバッグＥＣＵ１７は、ステップＳ９１３ｆにおいて、受信したリカバリデータと中断したブロック以外の更新後ソフトウェアのブロックから、中断したブロック（破損ブロック）を復元する。

　エアバッグＥＣＵ１７のようなメモリが少ないＥＣＵの場合は、単一の制御プログラムを上書きしながら更新を行う必要があるため、更新が中断した場合は、制御プログラムは正常動作できなくなる。このため、エアバッグＥＣＵ１７の更新が中断した場合、エアバッグ制御が行えないが、車両１の走行への影響は少ない。上記の通りリカバリ制御情報５０２ｆを構成し、これを用いることで、ゲートウェイ１０はエアバッグＥＣＵ１７の更新が中断した際は、すぐにＥＣＵを制御して更新を完了させなくてもよく、次のイグニッションＯＦＦ時に更新を再開すればよいことがわかる。また、ユーザに対して、更新が中断した旨と、そのためエアバッグ機能が使えない旨、中断した更新の再開はイグニッションＯＦＦ時に開始できる旨を、ＨＭＩ１２に警告画面を表示させることでユーザに伝達する。

　上述した第１の実施の形態によれば、次の作用効果が得られる。
（１）ソフトウェア更新装置、たとえばゲートウェイ１０は、制御装置、たとえばＥＣＵと接続され、ＥＣＵのソフトウェア、たとえば制御プログラムを更新前状態から更新完了状態へと遷移させる更新処理を行う更新制御部１０００１と、リカバリ制御情報５０２を取得するリカバリ制御情報管理部１０００５と、更新処理の異常により制御プログラムが更新完了状態へと遷移されていない場合に、リカバリ制御情報５０２に基づき制御プログラムを更新完了状態に遷移させるリカバリ処理を実行するリカバリ制御部１０００４とを備える。
　ゲートウェイ１０は、リカバリ制御情報５０２に基づきＥＣＵのリカバリ処理を実行するので、リカバリ制御情報５０２の記載に基づき様々なリカバリ処理を実行可能であり、多様な装置、たとえば多様なＥＣＵに対応したリカバリ処理を実行できる。換言すると、リカバリ制御情報５０２に基づいて更新に異常が発生した際のリカバリ制御処理を実行することで、リソースや特性の異なる多数のＥＣＵからなるシステムで更新に異常が発生した場合でも、適切なリカバリ処理を行うことができる。

（２）リカバリ制御情報５０２はリカバリ処理を開始するタイミングの情報である開始タイミング５０２１２を含む。そのため、ゲートウェイ１０はリカバリ制御情報５０２に基づきリカバリを実行するタイミングを、即時実施や次回のイグニッションＯＦＦ時など多様な対応が可能である。リカバリ制御情報５０２における開始タイミング５０２１２の設定は、たとえば車両におけるそのＥＣＵの役割に応じて決定される。

（３）ゲートウェイ１０は、車両に搭載され制御装置が車両のエンジン、およびブレーキの少なくとも一方を制御する装置である場合に、リカバリ制御情報はリカバリ処理を開始するタイミングが即時であることを示す情報を含む。そのためゲートウェイ１０は、車両の走行に不可欠なエンジン制御ＥＣＵ１３やブレーキ制御ＥＣＵ１４に対して、即時にリカバリ処理を開始することができる。

（４）リカバリ制御情報５０２は、リカバリ処理の方式を示す情報を含む。そのためゲートウェイ１０は、差分リジューム、圧縮リカバリ、サーバ連携、ブロックリカバリなどのリカバリ処理の方式をリカバリ制御情報５０２に基づき、ＥＣＵごとに使い分けることができる。

（５）リカバリ処理の方式は、ＥＣＵの構成、たとえばメモリ容量の多少に基づき決定されている。ＥＣＵの種類により処理に必要なリソースの量がある程度特定されるため、ＥＣＵの構成はＥＣＵの種類とも関連がある。すなわち、リカバリ処理の方式はＥＣＵの種類に基づき決定されているとも言える。そのため、ＥＣＵの構成やＥＣＵの種類に応じて適切なリカバリ処理を実施できる。

（６）リカバリ制御情報５０２は、リカバリ処理の方式に対応するリカバリデータを含む。そのためゲートウェイ１０は、リカバリ制御情報５０２に含まれるリカバリデータを用いてリカバリ処理を実行することができる。

（７）リカバリ制御情報５０２は、画面表示のための情報である表示内容５０２１３を含み、ソフトウェア更新装置は画面表示のための情報に基づき、リカバリ処理による車両１の機能制限状態を車両１の乗員であるユーザに告知する画面として、図１３（ｃ）、図１５（ｃ）、図１７（ｃ）、図１９（ｃ）、図２１（ｃ）、図２３（ｃ）のような画面を表示するための信号をＨＭＩ１２に出力する表示制御部、すなわちリカバリ制御部１０００４を備える。
　そのためゲートウェイ１０は、リカバリ処理の実行中には車両１の機能がどのように制限されるかをユーザに告知することができ、ユーザに状況を伝達することでユーザの利便性を向上させることができる。

（変形例１）
　上述した実施の形態では、ゲートウェイ１０がそれぞれのＥＣＵに搭載された制御プログラムを更新する、いわばソフトウェア更新装置の役割を担っていた。しかし、上述したゲートウェイプログラム１００が有する機能が通信モジュール１１やＨＭＩ１２に搭載されていてもよい。さらに、車内ネットワーク１０ａや１０ｂに接続される、不図示の他の装置がゲートウェイプログラム１００が有する機能を備えてもよい。

（変形例２）
　上述した第１の実施の形態では、ゲートウェイ１０がリカバリデータＵＲＩ５０２１５にアクセスすると圧縮されたソフトウェアが得られるとした。しかしリカバリデータＵＲＩ５０２１５により識別されるリソースは、更新後のソフトウェアから現行のソフトウェアへロールバックするための差分データ、ソフトウエアのブロックのＸＯＲデータ、さらには破損したブロックのデータでもよい。そしてゲートウェイ１０は、受信したデータに適合する処理を実行する。

（変形例３）
　リカバリ制御情報５０２に含まれるリカバリデータＵＲＩ５０２１５には、リカバリ方式５０２１４が「サーバ連携」以外の場合は、情報が設定されていないことを意味する「ＮＵＬＬ」が設定された。しかしリカバリデータがＥＣＵリカバリ制御情報５０２に含まれる場合には、リカバリデータＵＲＩ５０２１５にそのことを示す「ＬＯＣＡＬ」が設定されてもよい。

（変形例４）
　第１の実施の形態では、リカバリは更新処理の異常によりソフトウェアが更新完了状態へと遷移されていない場合に、更新完了状態に遷移させることであると定義した。しかし、リカバリを更新処理の異常によりソフトウェアが更新完了状態へと遷移されていない場合に、更新前状態に遷移させることとしてもよい。換言すると、いわゆるロールバックをリカバリとしてもよい。この場合は、ＥＣＵリカバリデータ５０２２にロールバックを実行するために必要な情報、たとえば、更新前のソフトウェアのブロック間のＸＯＲデータが含まれ、リカバリ制御部１０００４はＥＣＵリカバリデータ５０２２を用いてロールバックを実行する。

（変形例５）
　ゲートウェイ１０は、リカバリ処理を実行する際にネットワーク帯域を通常より多く使用してもよい。たとえばゲートウェイ１０は、通常は１秒あたりのデータ送信回数、または１秒あたりに送信するデータ量をネットワークの負荷に対して十分な余裕を持った設定とする。そしてゲートウェイ１０は、リカバリ処理を実行する際は通常よりも多いデータ送信回数、または通常よりも多いデータ量を許容する。これにより、リカバリ処理を迅速に実行できる。

　またゲートウェイ１０は、ネットワーク帯域を通常より多く使用することに代えて、もしくはネットワーク帯域を通常より多く使用するとともに、リカバリ処理に関連するデータフレームの優先度を通常より高く設定してもよい。
　さらにゲートウェイ１０は、全てのリカバリ処理についてネットワーク帯域を通常より多く使用するのではなく、特定の条件下においてのみネットワーク帯域を通常より多く使用してもよい。特定の条件とは、たとえばＥＣＵリカバリ制御情報５０２１の表示内容５０２１３が「緊急」であることや、リカバリ方式５０２１４において帯域を増加させることが明示されていることである。

（変形例６）
　ＥＣＵ更新制御情報５０１２に含まれる更新制御手順と、ＥＣＵリカバリ制御情報５０２１のリカバリ方式５０２１４の組み合わせが、特定の組み合わせであってもよい。たとえば更新制御手順が差分更新であり、リカバリ方式５０２１４が圧縮リカバリの組み合わせであってもよい。
　図２５は、変形例６において更新対象がブレーキ制御ＥＣＵ１４のみの場合の更新パッケージ５ｄの構成を示す図である。ブレーキ制御ＥＣＵ更新制御情報５０１２ｄは、図２５（ｂ）に示すように、たとえばＥＣＵを識別するＥＣＵ　ＩＤ５０１２１ｄ、更新を開始するタイミングを示す開始タイミング５０１２２ｄ、更新制御手順を示す更新方式５０１２４ｄから構成される。更新方式５０１２４ｄが差分更新なので、ブレーキ制御ＥＣＵ更新データ５０１３ｄは最新ソフトウエアと現行ソフトウエアとの差分データである。リカバリ方式５０２１４ｄは圧縮リカバリなので、ブレーキ制御ＥＣＵリカバリデータ５０２２ｄは圧縮された最新ソフトウエアである。

　この場合は、通常は短時間で処理が完了する更新方式が差分更新を実行し、更新に異常が生じた場合はソフトウェアの全領域の書込みを行うことで、確実にリカバリを行うことができる。そのため、処理の迅速性と安全性の確保を両立させることができる。
　なお、更新制御手順が差分更新であり、リカバリ方式５０２１４がサーバ連携であり、リカバリデータＵＲＩに基づき取得されるデータが圧縮された最新版のソフトウエアであってもよい。
　また、「リカバリ」の定義を、更新処理の異常によりソフトウェアが更新完了状態へと遷移されていない場合に、更新完了状態または更新前の状態に遷移させることとする場合は、図２５に示した例は以下のとおりでもよい。すなわち、ブレーキ制御ＥＣＵ更新データ５０１３ｄは最新ソフトウエアと現行ソフトウエアとの差分データであり、ブレーキ制御ＥＣＵリカバリデータ５０２２ｄは圧縮された現行のソフトウエアであってもよい。

―第２の実施の形態―
　図２６～図２７を参照して、ソフトウェア更新システムＳの第２の実施の形態を説明する。以下の説明では、第１の実施の形態と同じ構成要素には同じ符号を付して相違点を主に説明する。特に説明しない点については、第１の実施の形態と同じである。本実施の形態では、主に、ソフトウェアが更新されるＥＣＵにリカバリ制御情報が格納されている点で、第１の実施の形態と異なる。

（構成）
　第２の実施の形態におけるゲートウェイ１０のハードウェア構成、およびゲートウェイプログラム１００の構成は第１の実施の形態と同様である。ただしゲートウェイプログラム１００の動作が後述するように一部異なる。
　第２の実施の形態におけるＥＣＵのハードウェア構成は第１の実施の形態と同様である。ＥＣＵの制御プログラムの構成を説明する。
　図２６は、第２の実施の形態におけるエンジン制御ＥＣＵ１３上で動作する制御プログラム１３０の構成を示すブロック図である。ただし本実施の形態においてソフトウェアが更新される対象となるＥＣＵはいずれも、少なくとも図２６に示す制御プログラム１３０と同様の構成を備える。

　第２の実施の形態における制御プログラム１３０は、第１の実施の形態における構成に加えてリカバリ制御情報１３００７の記憶領域をさらに備える。このリカバリ制御情報１３００７には、第１の実施の形態におけるリカバリ制御情報５０２と同様の情報が含まれる。ただしリカバリ制御情報１３００７はリカバリ制御情報１３００７を格納するＥＣＵ、すなわちエンジン制御ＥＣＵ１３についての情報のみが格納される。換言すると、リカバリ制御情報１３００７には１つのＥＣＵリカバリ制御情報が含まれ、最大で１つのＥＣＵリカバリデータが含まれる。リカバリ制御情報１３００７は、エンジン制御ＥＣＵ１３の工場出荷時にあらかじめ設定されてもよいし、出荷後に設定されてもよい。リカバリ制御情報１３００７以外の構成要素は、図４（ｂ）の構成と同様である。

（リカバリ制御情報の取得動作）
　図２７は、ゲートウェイ１０がエンジン制御ＥＣＵ１３からリカバリ制御情報１３００７を取得する処理を示すシーケンス図である。ゲートウェイ１０は、エンジン制御ＥＣＵ１３の制御ソフトウェアを更新する前、たとえば更新の直前に以下のようにエンジン制御ＥＣＵ１３からリカバリ制御情報１３００７を取得する。
　ゲートウェイ１０の更新制御部１０００１は、エンジン制御ＥＣＵ１３にリカバリ制御情報取得要求を送信する（Ｓ８０１）。エンジン制御ＥＣＵ１３の更新制御部１３００１は、リカバリ制御情報取得要求を受信すると、リカバリ制御情報１３００７を読み出し、これをゲートウェイ１０に送信する（Ｓ８０２）。これを受信したゲートウェイ１０は、受信したリカバリ制御情報１３００７を用いて第１の実施の形態と同様にリカバリ処理を実行する。
　なおここでは、エンジン制御ＥＣＵ１３を例に説明を行ったが、他のＥＣＵも同様の構成及びシーケンスで実施できる。

　上述した第２の実施の形態によれば、次の作用効果が得られる。
（１）ＥＣＵは、当該ＥＣＵのリカバリ処理に用いられる情報であるリカバリ制御情報１３００７の記憶領域を備え、ゲートウェイ１０からの要求に応じてリカバリ制御情報１３００７を提供する。
　そのためゲートウェイ１０は、ＥＣＵごとのリカバリ処理に関する情報を、インターネット３を介して接続されるサーバ２ではなく物理的に近くに存在するＥＣＵから取得してリカバリ処理を行うことができる。また、ＥＣＵの追加・交換等により実際の車両の構成とサーバ２で管理されている車両の構成の不一致が生じた場合にはサーバからは適切なリカバリ制御情報が取得できなくなるが、サーバ２と実際の車両システムの構成に相違生じた場合でも、適切にリカバリ制御を行うことができる。

　―第３の実施の形態―
　図２８～図３０を参照して、ソフトウェア更新システムＳの第３の実施の形態を説明する。以下の説明では、第１の実施の形態と同じ構成要素には同じ符号を付して相違点を主に説明する。特に説明しない点については、第１の実施の形態と同じである。本実施の形態では、主に、リカバリ制御情報が中断要因ごとに格納されている点で、第１の実施の形態と異なる。また、本実施の形態における「リカバリ」とは、更新処理の異常によりソフトウェアが更新完了状態へと遷移されていない場合であって、かつ、致命的な異常により更新完了状態に遷移させることができない場合に、ユーザにその旨を通知する動作も含む。ユーザは当該通知により、車両に致命的な異常が発生したことを確認し、ディーラに連絡等必要な手段を講じることができる。

　（構成）
　第３の実施の形態におけるゲートウェイ１０のハードウェア構成、およびゲートウェイプログラム１００の構成は第１の実施の形態と同様である。ただしゲートウェイプログラム１００の動作が後述するように一部異なる。
　第３の実施の形態におけるＥＣＵのハードウェア構成は第１の実施の形態と同様である。

　図２８（ａ）は、第３の実施の形態における更新パッケージ５の構成例である。図２８（ａ）に示すように、第３の実施の形態における更新パッケージ５の構成は第１の実施の形態と同様であり、ＥＣＵリカバリ制御情報に符号５０２３を用いる点と以下に説明するようにＥＣＵリカバリ制御情報５０２３の構成が第１の実施の形態と異なる。
　図２８（ｂ）は、第３の実施の形態におけるＥＣＵリカバリ制御情報５０２３の構成を示す図である。ＥＣＵリカバリ制御情報５０２３は、第１の実施の形態におけるＥＣＵリカバリ制御情報５０２１の構成に加えて、１つのリカバリ制御情報数５０２３１、および１つ以上の中断要因５０２３２をさらに備える。そしてＥＣＵリカバリ制御情報５０２３には、それぞれの中断要因５０２３２に対応する、開始タイミング５０２１２、表示内容５０２１３、リカバリ方式５０２１４、およびリカバリデータＵＲＩ５０２１５が含まれる。リカバリ制御情報数５０２３１は、ＥＣＵリカバリ制御情報５０２３に中断要因５０２３２がいくつ含まれるかを示す。中断要因５０２３２は、更新が中断した要因を示す。以下では、ＥＣＵリカバリ制御情報５０２３に含まれる中断要因５０２３２、開始タイミング５０２１２、表示内容５０２１３、リカバリ方式５０２１４、およびリカバリデータＵＲＩ５０２１５の組み合わせを、要因別リカバリ制御情報５０２３０と呼ぶ。

（動作例）
　図２９及び図３０を用いて、自動運転ＥＣＵ１５について、中断要因ごとに異なるリカバリ制御を行う場合の場合のリカバリ制御情報５０２３ａの構成例、ＨＭＩ１２への表示例、更新状態Ｄ１ａの構成例、および動作シーケンスを示す。

　第３の実施の形態におけるリカバリ制御情報５０２３ａは、図２９（ａ）に示すように、ＥＣＵ　ＩＤ５０２１１ａ、リカバリ制御情報数５０２３１ａ、および要因別リカバリ制御情報５０２３０ａから構成される。ＥＣＵ　ＩＤ５０２１１ａには「自動運転ＥＣＵ」が設定され、リカバリ制御情報数５０２３１には「２」が設定され、第１の中断要因５０２３２ａには「電源断・通信断」が設定され、開始タイミング５０２１２ａには「走行開始」が設定され、表示内容５０２１３ａには「注意喚起」および不図示の表示メッセージ情報が設定され、リカバリ方式５０２１４ａには「差分リジューム」が設定され、リカバリデータＵＲＩ５０２１５ａには情報が設定されていないことを意味する「ＮＵＬＬ」が設定される。第２の中断要因５０２３２ａ２には「即時」が設定され、開始タイミング５０２１２ａ２には「即時」が設定され、表示内容５０２１３ａ２には「緊急」および不図示の表示メッセージ情報としてディーラへの誘導を促す情報が設定され、リカバリ方式５０２１４ａ２には情報が設定されていないことを意味する「ＮＵＬＬ」が設定され、リカバリデータＵＲＩ５０２１５ａ２には情報が設定されていないことを意味する「ＮＵＬＬ」が設定される。

　リカバリ制御部１０００４は、表示内容５０２１３ａ２に基づきＨＭＩ１２の表示装置に図２９（ｂ）に示す画面表示Ｇ１０ａ２を出力させる。この画面表示Ｇ１０ａ２は、ソフトウェアの更新が致命的エラーにより中断されており、リカバリするためにはディーラーに連絡する必要があることを示す表示である。

　第３の実施の形態における更新状態Ｄ１ａは、図２９（ｃ）に示すように、第１の実施の形態における更新状態Ｄ１の情報に加え、中断要因Ｄ１０６を備える。中断要因Ｄ１０６は、更新が中断した要因が格納されるフィールドであり、例えば「電源断」「通信断」「ＦＲＯＭ故障」などが格納される。

　レコードＤ１１ａは第３の実施の形態において自動運転ＥＣＵ１５の更新状態を示すレコードであり、中断要因Ｄ１０６のフィールドには「ＦＲＯＭ故障」が格納されている。このように、中断要因Ｄ１０６を記録することにより、更新が中断した要因を認識して適切なリカバリ処理を開始することができる。

　図３０は、第３の実施の形態における自動運転ＥＣＵ１５のリカバリ処理の１例を示すシーケンス図である。たとえば、自動運転ＥＣＵ１５の更新処理が、ゲートウェイ１０への電源供給断などにより中断された後で電源供給が再開された後や、自動運転ＥＣＵ１５のＦＲＯＭの故障により中断した後に、再度イグニッションがＯＮされると、以下のようにリカバリ処理が実行される。
　ゲートウェイ１０が起動すると、最初に、ステップＳ９０１ａにおいて中断中の更新の有無を確認する（図１１のＳ７０１、Ｓ７０２、図３０のＳ９０１ａ）。

　また、ゲートウェイ１０の処理と並行して、自動運転ＥＣＵ１５では、図１０（ｂ）に示した起動処理を行う。ここでは、更新が中断し、起動情報Ｄ３３はまだ書き換わっておらずプログラムエリア１３１３ｂＰ０に記録された制御プログラムの起動が指定されているため、自動運転ＥＣＵ１５は現行のバージョン２の制御プログラムＰ４を起動する。
　ゲートウェイ１０は、更新状態Ｄ２１の更新開始状態Ｄ１０２から自動運転ＥＣＵ１５の更新が中断していると判定すると（Ｓ９０１ａ）、ステップＳ９１０ａ２において以下の処理を行う。すなわちゲートウェイ１０は、更新状態Ｄ１ａから自動運転ＥＣＵ１５に該当する中断要因Ｄ１０６を読み出し、中断要因を判定する。中断要因が「電源断・通信断」の場合（Ｓ９１０ａ２：「通信断・電源断」）、次に、ステップＳ９１１ａ２において自動運転ＥＣＵリカバリ制御情報５０２３ａから中断要因が「電源断・通信断」であるリカバリ制御情報を読み出し、リカバリ制御情報に基づくリカバリ処理を行う。中断要因が「電源断・通信断」であるリカバリ制御情報に基づくリカバリ処理は、図１４のステップＳ９０３ａからステップＳ９０９ａまでの処理と同じである。中断要因が「ＦＲＯＭ故障」である場合（Ｓ９１０ａ２：「ＦＲＯＭ故障」）、次に、ステップＳ９１２ａ２において自動運転ＥＣＵリカバリ制御情報５０２３ａから中断要因が「ＦＲＯＭ故障」であるリカバリ制御情報を読み出し、リカバリ制御情報に基づくリカバリ処理を行う。

　中断要因が「ＦＲＯＭ故障」であるリカバリ制御情報に基づくリカバリ処理は、図３０（ｂ）に示す手順で行われる。すなわち、ゲートウェイ１０は、自動運転ＥＣＵ１５に該当する自動運転ＥＣＵリカバリ制御情報５０２３から中断要因が「ＦＲＯＭ故障」である場合の開始タイミング５０２１２ａ２を読み出し、自動運転ＥＣＵ１５のリカバリ処理を開始するタイミングが、即時であると判定する。次にゲートウェイ１０は、ステップＳ９０３ａ２において自動運転ＥＣＵリカバリ制御情報５０２３から中断要因が「ＦＲＯＭ故障」である場合の表示内容５０２１３ａ２を読み出し、表示内容５０２１３ａ２に基づく緊急画面を表示する要求をＨＭＩ１２に発行する（Ｓ９１１ａ２）。ＨＭＩ１２は、この要求に基づき図２９（ｂ）のＧ１０ａ２に例示する緊急画面を表示装置に表示する（Ｓ９１２ａ２）。

　上述した第３の実施の形態によれば、以下の作用効果が得られる。
　（１）リカバリ制御情報５０２３は、異常要因ごとのリカバリ制御情報を備え、ゲートウェイ１０は、異常要因に応じて適用するリカバリ処理を選択する。
　更新が中断する要因がＦＲＯＭの故障の場合などは、ハードウェアの交換などが必要となり、システム単独でリカバリを行うことが困難であるなど、中断要因によっては、適用可能なリカバリ処理が異なる可能性がある。上記の通りリカバリ制御情報５０２３を構成し、これを用いることで、ゲートウェイ１０は、例えばＥＣＵに致命的な異常が発生した場合とそうでない場合で、異なるリカバリ処理を実行し、ユーザに適切な情報を伝えることができる。

　なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。たとえば、上記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることや各処理における処理の順番を入れ替えることも可能である。たとえば、本実施の形態ではソフトウェア更新装置はゲートウェイ１０であるとしたが、通信モジュール１１やＨＭＩ１２がソフトウェア更新装置であってもよい。

　また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、たとえば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するソフトウェアを解釈し、実行することによりソフトウェアで実現してもよい。
　また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。
　上記では、種々の実施の形態および変形例を説明したが、本発明はこれらの内容に限定されるものではない。本発明の技術的思想の範囲内で考えられるその他の態様も本発明の範囲内に含まれる。

　次の優先権基礎出願の開示内容は引用文としてここに組み込まれる。
　日本国特許出願２０１６年第２０２７６７号（２０１６年１０月１４日出願）

　　　　　Ｓ　…　ソフトウェア更新システム
　　　　　１　…　車両
　　　　　２　…　サーバ
　　　　１０　…　ゲートウェイ
　　　　１３　…　エンジン制御ＥＣＵ
　　　　１４　…　ブレーキ制御ＥＣＵ
　１０００１　…　更新制御部
　１０００４　…　リカバリ制御部
　１０００５　…　リカバリ制御情報管理部
　　　５０２　…　ＥＣＵリカバリ制御情報
　　５０２１　…　ＥＣＵリカバリ制御情報
　　５０２２　…　ＥＣＵリカバリデータ
　５０２１２　…　リカバリ開始タイミング
　５０２１２　…　開始タイミング
　５０２１３　…　表示内容
　５０２１４　…　リカバリ方式

Claims

　制御装置と接続されるソフトウェア更新装置であって、
　前記制御装置のソフトウェアを更新前状態から更新完了状態へと遷移させる更新処理を行う更新制御部と、
　リカバリ制御情報を取得するリカバリ制御情報管理部と、
　前記更新処理の異常により前記ソフトウェアが前記更新完了状態へと遷移されていない場合に、前記リカバリ制御情報に基づき前記ソフトウェアを前記更新完了状態に遷移させるリカバリ処理を実行するリカバリ制御部とを備えるソフトウェア更新装置。
　請求項１に記載のソフトウェア更新装置において、
　前記リカバリ制御情報は前記リカバリ処理を開始するタイミングの情報を含むソフトウェア更新装置。
　請求項２に記載のソフトウェア更新装置において、
　前記ソフトウェア更新装置は車両に搭載され、
　前記制御装置が前記車両のエンジン、およびブレーキの少なくとも一方を制御する装置である場合に、前記リカバリ制御情報は前記リカバリ処理を開始するタイミングが即時であることを示す情報を含むソフトウェア更新装置。
　請求項１に記載のソフトウェア更新装置において、
　前記リカバリ制御情報は前記リカバリ処理の方式を示す情報を含むソフトウェア更新装置。
　請求項４に記載のソフトウェア更新装置において、
　前記リカバリ処理の方式を示す情報は、前記制御装置の構成に基づき決定されたソフトウェア更新装置。
　請求項４に記載のソフトウェア更新装置において、
　前記リカバリ制御情報は、前記リカバリ処理の方式に対応するリカバリデータを含むソフトウェア更新装置。
　請求項１に記載のソフトウェア更新装置において、
　前記ソフトウェア更新装置は、車両に搭載されると共に、画面表示を行う表示装置と接続されており、
　前記リカバリ制御情報は前記画面表示のための情報を含み、
　前記ソフトウェア更新装置は、
　前記画面表示のための情報に基づき、前記リカバリ処理による前記車両の機能制限状態を前記車両の乗員に告知する画面を表示するための信号を前記表示装置に出力する表示制御部をさらに備えるソフトウェア更新装置。
　制御装置と接続されるソフトウェア更新装置が実行するソフトウェア更新方法であって、
　前記制御装置のソフトウェアを更新前状態から更新完了状態へと遷移させる更新処理を行うことと、
　リカバリ制御情報を取得することと、
　前記更新処理の異常により前記ソフトウェアが前記更新完了状態へと遷移されていない場合に、前記リカバリ制御情報に基づき前記ソフトウェアを前記更新完了状態に遷移させるリカバリ処理を実行することとを有するソフトウェア更新方法。
　請求項８に記載のソフトウェア更新方法において、
　前記リカバリ制御情報は前記リカバリ処理を開始するタイミングの情報を含むソフトウェア更新方法。
　請求項９に記載のソフトウェア更新方法において、
　前記ソフトウェア更新装置は車両に搭載され、
　前記制御装置が前記車両のエンジン、およびブレーキの少なくとも一方を制御する装置である場合に、前記リカバリ制御情報は前記リカバリ処理を開始するタイミングが即時であることを示す情報を含むソフトウェア更新方法。
　請求項８に記載のソフトウェア更新方法において、
　前記リカバリ制御情報は前記リカバリ処理の方式を示す情報を含むソフトウェア更新方法。
　請求項１１に記載のソフトウェア更新方法において、
　前記リカバリ処理の方式を示す情報は、前記制御装置の構成に基づき決定されたソフトウェア更新方法。
　請求項１１に記載のソフトウェア更新方法において、
　前記リカバリ制御情報は、前記リカバリ処理の方式に対応するリカバリデータを含むソフトウェア更新方法。
　請求項８に記載のソフトウェア更新方法において、
　前記ソフトウェア更新装置は、車両に搭載されると共に、画面表示を行う表示装置と接続されており、
　前記リカバリ制御情報は前記画面表示のための情報を含み、
　前記ソフトウェア更新方法は、
　前記画面表示のための情報に基づき、前記リカバリ処理による前記車両の機能制限状態を前記車両の乗員に告知する画面を表示するための信号を前記表示装置に出力することをさらに有するソフトウェア更新方法。
　請求項１から請求項７までのいずれか１項に記載のソフトウェア更新装置と、
　前記ソフトウェア更新装置に前記リカバリ制御情報を送信するサーバとを備えるソフトウェア更新システム。