(57)【要約】【課題】揮発性メモリの容量が少ない制御装置であっても、プログラム更新の高速化を可能とする。【解決手段】ＥＣＵは、配信データＤＴ１０を受信するデータ送受信部１２０２と、データ送受信部１２０２により受信された配信データＤＴ１０から更新データＤＴ１００を解凍する更新データ解凍部１２０４と、更新データ解凍部１２０４により解凍された更新データＤＴ１００を用いて、指定された更新方式に従って更新後の新プログラムデータＤＴ１２３を復元する新プログラム復元部１２０５とを備える。更新データ解凍部１２０４は、指定された更新方式に基づいて、更新データＤＴ１００を解凍する際の解凍方法を切り替える。【選択図】図８
2018180948.tif 000002
【特許請求の範囲】
【請求項１】
複数の更新方式のうちいずれかを指定する情報を有するヘッダと、圧縮された更新データと、を含む配信データを受信する受信部と、
前記受信部により受信された前記配信データから前記更新データを解凍する解凍部と、
前記解凍部により解凍された前記更新データを用いて、前記ヘッダで指定された更新方式に従って更新後の新プログラムを復元する復元部と、を備え、
前記解凍部は、前記ヘッダで指定された更新方式に基づいて、前記更新データを解凍する際の解凍方法を切り替える制御装置。
【請求項２】
請求項１に記載の制御装置において、
前記更新方式は、更新前の旧プログラムと前記新プログラムとの差分を圧縮して前記更新データを生成する差分更新方式と、前記新プログラムを圧縮して前記更新データを生成する圧縮更新方式と、を含み、
前記解凍部は、
前記ヘッダで指定された更新方式が前記差分更新方式である場合は、第１の解凍方式を用いて前記更新データを解凍し、
前記ヘッダで指定された更新方式が前記圧縮更新方式である場合は、前記第１の解凍方式とは異なる第２の解凍方式を用いて前記更新データを解凍する制御装置。
【請求項３】
請求項２に記載の制御装置において、
前記制御装置は、揮発性メモリおよび不揮発性メモリを備えており、
前記第１の解凍方式は、前記不揮発性メモリを使用せずに前記揮発性メモリを使用して前記更新データを解凍する手法であり、
前記第２の解凍方式は、前記揮発性メモリおよび前記不揮発性メモリを使用して前記更新データを解凍する手法である制御装置。
【請求項４】
請求項３に記載の制御装置において、
前記配信データの送信元に対して前記揮発性メモリの状態を通知する通知部をさらに備える制御装置。
【請求項５】
請求項１から請求項４のいずれか一項に記載の制御装置において、
前記制御装置は、車両に搭載されて前記車両に設けられた車内ネットワークと接続されており、
前記受信部は、前記車内ネットワークを介して前記配信データを受信する制御装置。
【請求項６】
ネットワークを介して互いに接続されたサーバと制御装置とを備え、
前記サーバは、
複数の更新方式のうちいずれかに従って、圧縮された更新データを生成するデータ圧縮部と、
前記更新データの生成に用いた更新方式を指定する情報を有するヘッダと、前記更新データと、を含む配信データを、前記ネットワークを介して前記制御装置に送信する送信部と、を備え、
前記制御装置は、
前記配信データを受信する受信部と、
前記受信部により受信された前記配信データから前記更新データを解凍する解凍部と、
前記解凍部により解凍された前記更新データを用いて、前記ヘッダで指定された更新方式に従って更新後の新プログラムを復元する復元部と、を備え、
前記解凍部は、前記ヘッダで指定された更新方式に基づいて、前記更新データを解凍する際の解凍方法を切り替えるプログラム更新システム。
【請求項７】
請求項６に記載のプログラム更新システムにおいて、
前記更新方式は、更新前の旧プログラムと前記新プログラムとの差分を圧縮して前記更新データを生成する差分更新方式と、前記新プログラムを圧縮して前記更新データを生成する圧縮更新方式と、を含み、
前記解凍部は、
前記ヘッダで指定された更新方式が前記差分更新方式である場合は、第１の解凍方式を用いて前記更新データを解凍し、
前記ヘッダで指定された更新方式が前記圧縮更新方式である場合は、前記第１の解凍方式とは異なる第２の解凍方式を用いて前記更新データを解凍するプログラム更新システム。
【請求項８】
請求項７に記載のプログラム更新システムにおいて、
前記制御装置は、揮発性メモリおよび不揮発性メモリを備えており、
前記第１の解凍方式は、前記不揮発性メモリを使用せずに前記揮発性メモリを使用して前記更新データを解凍する手法であり、
前記第２の解凍方式は、前記揮発性メモリおよび前記不揮発性メモリを使用して前記更新データを解凍する手法であり、
前記データ圧縮部は、前記圧縮更新方式に従って前記更新データを生成する場合には、前記差分更新方式に従って前記更新データを生成する場合よりも、前記圧縮に用いる辞書データの範囲を拡大するプログラム更新システム。
【請求項９】
請求項８に記載のプログラム更新システムにおいて、
前記制御装置は、前記サーバに対して前記揮発性メモリの状態を通知する通知部をさらに備え、
前記データ圧縮部は、前記通知部により通知された前記揮発性メモリの状態に基づいて、前記辞書データの範囲を設定するプログラム更新システム。
【請求項１０】
請求項６から請求項９のいずれか一項に記載のプログラム更新システムにおいて、
前記ネットワークは、車両に設けられた車内ネットワークと、前記車両の外部に設けられた車外ネットワークとを含み、
前記制御装置は、前記車両に搭載されて前記車内ネットワークと接続されており、
前記サーバは、前記車外ネットワークを介して前記車内ネットワークと通信可能であり、
前記送信部は、前記車外ネットワークおよび前記車内ネットワークを介して前記配信データを前記制御装置に送信するプログラム更新システム。
【請求項１１】
制御装置のプログラムを更新するプログラム更新方法であって、
前記制御装置により、複数の更新方式のうちいずれかを指定する情報を有するヘッダと、圧縮された更新データと、を含む配信データを受信し、
前記制御装置により、前記ヘッダで指定された更新方式に基づいて解凍方法を切り替えて、受信した前記配信データから前記更新データを解凍し、
前記制御装置により、解凍した前記更新データを用いて、前記ヘッダで指定された更新方式に従って更新後の新プログラムを復元するプログラム更新方法。
【請求項１２】
請求項１１に記載のプログラム更新方法において、
前記更新方式は、更新前の旧プログラムと前記新プログラムとの差分を圧縮して前記更新データを生成する差分更新方式と、前記新プログラムを圧縮して前記更新データを生成する圧縮更新方式と、を含み、
前記ヘッダで指定された更新方式が前記差分更新方式である場合は、前記制御装置により、第１の解凍方式を用いて前記更新データを解凍し、
前記ヘッダで指定された更新方式が前記圧縮更新方式である場合は、前記制御装置により、前記第１の解凍方式とは異なる第２の解凍方式を用いて前記更新データを解凍するプログラム更新方法。
【請求項１３】
請求項１２に記載のプログラム更新方法において、
前記制御装置は、揮発性メモリおよび不揮発性メモリを備えており、
前記第１の解凍方式は、前記不揮発性メモリを使用せずに前記揮発性メモリを使用して前記更新データを解凍する手法であり、
前記第２の解凍方式は、前記揮発性メモリおよび前記不揮発性メモリを使用して前記更新データを解凍する手法であるプログラム更新方法。
【請求項１４】
請求項１３に記載のプログラム更新方法において、
前記配信データを受信する前に、前記制御装置により、前記配信データの送信元に対して前記揮発性メモリの状態を通知するプログラム更新方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、制御装置、プログラム更新システムおよびプログラム更新方法に関する。
【背景技術】
【０００２】
近年の自動車には、様々な電子制御装置（ＥＣＵ：Ｅｌｅｃｔｒｏｎｉｃ  Ｃｏｎｔｒｏｌ  Ｕｎｉｔ）が搭載されている。各ＥＣＵは、様々なプログラムを実行すると共に、ＣＡＮ（Ｃｏｎｔｒｏｌｌｅｒ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）等の車載ネットワークを介して通信を行うことで、自動車の動作に関する様々な機能を実現している。
【０００３】
従来、これらのＥＣＵのプログラムを更新するリプログラミング手法として、ＣＡＮを介して新たなプログラムを各ＥＣＵに送信し、各ＥＣＵ内の不揮発性メモリに保存することが提案されている。しかしながら、自動車に搭載される様々なＥＣＵの中には、自動車の多機能化や自動車に搭載される各種センサの増加などに伴って、プログラムの増大化が進んでいるものがある。そのようなＥＣＵに対しては、リプログラミングに要する時間（以降「リプロ時間」と称する）が長くなるという問題がある。
【０００４】
ＥＣＵのリプロ時間の短縮に関して、特許文献１では、各ＥＣＵが対応可能なプログラムの更新方式の違いや、各ＥＣＵの状況に応じて、各ＥＣＵのリプログラミングにおいて適用する更新方式を切り替える手法を考案している。更新方式としては、新プログラムのデータを一定の大きさごとに分割し、分割した各データを圧縮してＥＣＵに送信する「圧縮更新方式」や、既にＥＣＵに保存されている旧プログラムと新プログラムとの差分データを圧縮してＥＣＵに送信する「差分更新方式」などがある。特許文献１の手法では、これらの更新方式を適用してＥＣＵに送信するデータの総量を削減することで、ＥＣＵのリプロ時間を短縮する効果が得られる。
【０００５】
また、ＥＣＵのリプロ時間の短縮に関して、特許文献２では、送信データの圧縮率を高めるアプローチも提案されている。ＬＺ７７などのいわゆる辞書式圧縮法によるデータ圧縮では、一般的に、データストリーム中の既出パターンを見つけるために参照される参照辞書のサイズを広げることで、データの圧縮率を高められる。特許文献２の手法では、データストリームを一連のブロック群に分割し、圧縮の対象ブロックと当該対象ブロックより前方のブロック群の圧縮結果とを参照辞書として当該対象ブロックを圧縮することで、圧縮率を高める効果が得られる。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２０１６−１７０７４０号公報
【特許文献２】特許第４８８８５６６号
【発明の概要】
【発明が解決しようとする課題】
【０００７】
圧縮データを受信した装置において、その圧縮データを解凍するためには、解凍したデータを一時的に保存するための解凍バッファを揮発性メモリ上に設ける必要がある。特許文献２に記載された従来の方法では、この解凍バッファの容量に合わせて、圧縮時に用いられる参照辞書のサイズが設定される。しかしながら、ＥＣＵのように自動車に搭載される装置では、一般的にハードウェア資源に余裕があまりなく、解凍バッファとして使用可能な揮発性メモリの容量が少ない。そのため、参照辞書のサイズをあまり大きくすることができず、圧縮率を高めることが困難である。このように従来の手法では、特許文献１のように複数の更新方式を切り替えてプログラム更新を行う場合に、プログラム更新の高速化が不十分であった。
【課題を解決するための手段】
【０００８】
本発明による制御装置は、複数の更新方式のうちいずれかを指定する情報を有するヘッダと、圧縮された更新データと、を含む配信データを受信する受信部と、前記受信部により受信された前記配信データから前記更新データを解凍する解凍部と、前記解凍部により解凍された前記更新データを用いて、前記ヘッダで指定された更新方式に従って更新後の新プログラムを復元する復元部と、を備え、前記解凍部は、前記ヘッダで指定された更新方式に基づいて、前記更新データを解凍する際の解凍方法を切り替える。
本発明によるプログラム更新システムは、ネットワークを介して互いに接続されたサーバと制御装置とを備え、前記サーバは、複数の更新方式のうちいずれかに従って、圧縮された更新データを生成するデータ圧縮部と、前記更新データの生成に用いた更新方式を指定する情報を有するヘッダと、前記更新データと、を含む配信データを、前記ネットワークを介して前記制御装置に送信する送信部と、を備え、前記制御装置は、前記配信データを受信する受信部と、前記受信部により受信された前記配信データから前記更新データを解凍する解凍部と、前記解凍部により解凍された前記更新データを用いて、前記ヘッダで指定された更新方式に従って更新後の新プログラムを復元する復元部と、を備え、前記解凍部は、前記ヘッダで指定された更新方式に基づいて、前記更新データを解凍する際の解凍方法を切り替える。
本発明によるプログラム更新方法は、制御装置のプログラムを更新する方法であって、前記制御装置により、複数の更新方式のうちいずれかを指定する情報を有するヘッダと、圧縮された更新データと、を含む配信データを受信し、前記制御装置により、前記ヘッダで指定された更新方式に基づいて解凍方法を切り替えて、受信した前記配信データから前記更新データを解凍し、前記制御装置により、解凍した前記更新データを用いて、前記ヘッダで指定された更新方式に従って更新後の新プログラムを復元する。
【発明の効果】
【０００９】
本発明によれば、揮発性メモリの容量が少ない制御装置であっても、プログラム更新の高速化が可能となる。
【図面の簡単な説明】
【００１０】
【図１】本発明の第１の実施形態に係るプログラム更新システムの構成例を示すブロック図である。
【図２】サーバのハードウェア構成例を示すブロック図である。
【図３】サーバのＣＰＵ上で動作するプログラム配信ソフトウェアの機能構成例を示すブロック図である。
【図４】サーバで動作するデータ圧縮部のソフトウェア内部構成例を示すブロック図である。
【図５】プログラム更新装置のハードウェア構成例を示すブロック図である。
【図６】プログラム更新装置のマイコン上で動作するプログラム更新管理ソフトウェアの機能構成例を示すブロック図である。
【図７】ＥＣＵのハードウェア構成例を示すブロック図である。
【図８】ＥＣＵのマイコン上で動作する本発明の第１の実施形態に係るプログラム復元ソフトウェアの機能構成例を示すブロック図である。
【図９】本発明の第１の実施形態に係るプログラム更新システムにおけるプログラム更新処理全体の流れを示すシーケンス図である。
【図１０】サーバが実行する更新データ生成処理の流れを示すフロー図である。
【図１１】データ圧縮部におけるデータ圧縮を説明する図である。
【図１２】サーバから配信される配信データの構造例を示す図である。
【図１３】プログラム更新装置およびＥＣＵが実行する配信データ転送準備処理、配信データ転送処理および配信データ転送完了処理の流れを示すシーケンス図である。
【図１４】プログラム更新装置とＥＣＵの間で送受信されるコマンドのデータ構造例を示す図である。
【図１５】配信データを分割送信する場合の構成例を示す図である。
【図１６】ＥＣＵが実行する解凍復元処理の流れを示すフロー図である。
【図１７】差動更新方式による解凍復元処理を説明する図である。
【図１８】圧縮更新方式による解凍復元処理を説明する図である。
【図１９】本発明の第２の実施形態に係るプログラム更新システムの構成例を示すブロック図である。
【図２０】本発明の第２の実施形態に係るプログラム復元ソフトウェアの機能構成例を示すブロック図である。
【図２１】本発明の第２の実施形態に係るプログラム更新システムにおけるプログラム更新処理全体の流れを示すシーケンス図である。
【発明を実施するための形態】
【００１１】
以下、本発明を実施するための形態について図面を用いて説明する。なお、図面において、同一符号は、同一または相当部分を示す。また、本発明は、図示例に限定されるものではない。
【００１２】
（第１の実施形態）
本発明における車両搭載ＥＣＵのプログラム更新方法について、第１の実施形態を説明する。なお、以降では、ＥＣＵのプログラムを更新する場合について説明するが、本技術は各種パラメータやデータなど、プログラムを含むＥＣＵの制御に必要な情報の全般について適用可能である。
【００１３】
図１は、本発明の第１の実施形態に係るプログラム更新システムの構成例を示すブロック図である。図１に示すプログラム更新システムは、サーバ１０と、車両１にそれぞれ搭載されたプログラム更新装置１１および複数のＥＣＵ１２、１３、１４等から構成されている。サーバ１０とプログラム更新装置１１は、車外ネットワーク２０（たとえばインターネットなど）を介して互いに接続されており、プログラム更新装置１１と各ＥＣＵは、車内ネットワーク２１（たとえばＣＡＮなど）を介して互いに接続されている。すなわち、サーバ１０と各ＥＣＵは、車外ネットワーク２０、プログラム更新装置１１および車内ネットワーク２１により構成されるネットワーク（以下、配信ネットワークと称する）を介して互いに接続されている。
【００１４】
サーバ１０は、車両１内の各ＥＣＵに対して、それぞれのＥＣＵの制御プログラムを更新するのに必要なデータである配信データＤＴ１０を配信する。プログラム更新装置１１は、サーバ１０と各ＥＣＵ間のネットワーク中継装置であり、配信ネットワークの一部として機能する。プログラム更新装置１１は、サーバ１０から車外ネットワーク２０を介して配信された配信データＤＴ１０を受信し、一時的に保存する。そして、配信データＤＴ１０の配信対象である各ＥＣＵに対して、車内ネットワーク２１を介して、保存した配信データＤＴ１０を転送する。各ＥＣＵは、プログラム更新装置１１から転送された配信データＤＴ１０を受信し、自らの記憶装置に保存することで制御プログラムを更新した後、再起動時などの所定のタイミングで、更新済みのプログラムを適用する。
【００１５】
図２は、サーバ１０のハードウェア構成例を示すブロック図である。図２に示すように、サーバ１０は、ＣＰＵ３１、記憶部３２、表示部３３、操作入力部３４、およびＷＡＮ通信装置３５を備える。
【００１６】
ＣＰＵ３１は、プログラム配信ソフトウェア４０を動作させるための演算処理装置である。記憶部３２は、揮発性メモリや不揮発性メモリにより構成され、プログラム配信ソフトウェア４０の処理に必要な各データを記憶する。表示部３３と操作入力部３４は、ユーザがサーバ１０を操作する際に使用するディスプレイと入力インタフェースである。ＷＡＮ通信装置３５は、車外ネットワーク２０を介して車両１と通信を行う。
【００１７】
なお、サーバ１０は必ずしもユーザ操作が必要ではなく、プログラム配信ソフトウェア４０を自動的に稼動させて、車両１の各ＥＣＵに対してプログラム更新用の配信データＤＴ１０を作成して配信しても良い。また、サーバ１０は、１台で構成される場合もあるし、複数台で連携して同一の機能を実現する場合もある。
【００１８】
図３は、サーバ１０のＣＰＵ３１上で動作するプログラム配信ソフトウェア４０の機能構成例を示すブロック図である。なお、本ブロック図は、プログラム配信ソフトウェア４０が有する機能をその種類ごとに分割された機能ブロックとして記載しているが、各機能ブロックをさらに分割したり、複数の機能ブロックを統合したりしてもよい。また、プログラム配信ソフトウェア４０は、１つのプログラムで実現される必要はなく、２以上のプログラムの組み合せによって実現されてもよい。
【００１９】
プログラム配信ソフトウェア４０は、配信制御部４１、差分データ生成部４２、データ圧縮部４３、データ配信部４４、データ送受信部４５の各機能ブロックを有する。サーバ１０において、ＣＰＵ３１によりプログラム配信ソフトウェア４０が実行されると、これらの機能ブロックがＣＰＵ３１により実現される。すなわち、サーバ１０は、ＣＰＵ３１においてプログラム配信ソフトウェア４０を実行することで、配信制御部４１、差分データ生成部４２、データ圧縮部４３、データ配信部４４、およびデータ送受信部４５を備えたものとして動作することができる。
【００２０】
記憶部３２には、プログラム配信ソフトウェア４０が取り扱うデータとして、更新管理データＤＴ４００、ＥＣＵ機能データＤＴ４０１、プログラムデータＤＴ４０２、差分データＤＴ４０３、および更新データＤＴ１００が記憶されている。また、データ圧縮時に用いられる作業領域として、圧縮入力バッファＢＦ１０１および圧縮出力バッファＢＦ１０２が設けられている。プログラムデータＤＴ４０２は、新プログラムデータＤＴ４０２１および旧プログラムデータＤＴ４０２２により構成される。プログラム配信ソフトウェア４０の各機能ブロックは、記憶部３２に対してこれらのデータの読み書きを行う。
【００２１】
更新管理データＤＴ４００は、各ＥＣＵのプログラム更新状況を管理するための情報である。更新管理データＤＴ４００は、たとえば、各ＥＣＵの更新データの生成状況、配信予定、配信完了状況などの情報を含む。プログラム配信ソフトウェア４０は、更新管理データＤＴ４００に基づいて、差分データＤＴ４０３の生成、更新データＤＴ１００の生成、配信データＤＴ１０の配信などの実行判断を行う。
【００２２】
ＥＣＵ機能データＤＴ４０１は、各ＥＣＵが対応している更新方式や、各ＥＣＵが更新データを解凍する際に使用可能なＲＡＭ容量やＲＯＭ容量など、各ＥＣＵのリソースに関する情報を含む。これらのリソースを把握することで、サーバ１０から配信データＤＴ１０を効率よく配信できるようにする。
【００２３】
なお、本実施形態のプログラム更新システムにおいて、各ＥＣＵは、「全更新方式」、「差分更新方式」、「圧縮更新方式」の３つの更新方式のうち、少なくともいずれか一つの更新方式に対応しているものとする。全更新方式とは、新プログラムデータＤＴ４０２１を圧縮せずにそのまま更新データＤＴ１００として用いて、これに基づく配信データＤＴ１０をサーバ１０から各ＥＣＵに配信する更新方式である。差分更新方式とは、旧プログラムデータＤＴ４０２２と新プログラムデータＤＴ４０２１との差分に基づく差分データＤＴ４０３を圧縮することで、更新データＤＴ１００を生成し、これに基づく配信データＤＴ１０をサーバ１０から各ＥＣＵに配信する更新方式である。圧縮更新方式とは、新プログラムデータＤＴ４０２１を圧縮することで、更新データＤＴ１００を生成し、これに基づく配信データＤＴ１０をサーバ１０から各ＥＣＵに配信する更新方式である。差分更新方式および圧縮更新方式については、後で詳しく説明する。
【００２４】
プログラムデータＤＴ４０２は、各ＥＣＵに配信予定の新たなプログラムデータである新プログラムデータＤＴ４０２１と、各ＥＣＵで既に稼働している更新前のプログラムデータである旧プログラムデータＤＴ４０２２とを含む。これらのプログラムデータは、ＥＣＵごとに個別のデータであってもよいし、複数のＥＣＵで共通のデータであってもよい。また、プログラム以外のデータ、たとえば各種のパラメータデータや設定データ等を含んでいてもよい。
【００２５】
差分データＤＴ４０３は、差分更新方式によるプログラム更新を行う際に、旧プログラムデータＤＴ４０２２と新プログラムデータＤＴ４０２１との間のデータ差異を抽出したものである。これらのプログラムデータを比較し、特定のデータ列のみ差異があれば、その差異が差分データＤＴ４０３として抜き出され、差異が生じたデータ列の位置情報（たとえば開始位置とデータ長）と合わせて記録される。旧プログラムデータＤＴ４０２２と新プログラムデータＤＴ４０２１の差異が少ない場合は、圧縮更新方式により新プログラムデータＤＴ４０２１を全て更新対象のＥＣＵに送信するよりも、差分更新方式により差分データＤＴ４０３のみを更新対象のＥＣＵに送信し、既に当該ＥＣＵに保存されている旧プログラムデータＤＴ４０２２にその差異を適用することで、新プログラムデータＤＴ４０２１を効率よく復元することができる。
【００２６】
更新データＤＴ１００は、サーバ１０から各ＥＣＵに配信される配信データＤＴ１０の元となるデータである。前述のように、全更新方式の場合は、新プログラムデータＤＴ４０２１が圧縮せずにそのまま更新データＤＴ１００とされる。一方、圧縮更新方式の場合は、新プログラムデータＤＴ４０２１が圧縮されたものが更新データＤＴ１００として生成される。また、差分更新方式の場合は、差分データＤＴ４０３が圧縮されたものが更新データＤＴ１００として生成される。
【００２７】
続けて、プログラム配信ソフトウェア４０により実現されるサーバ１０の各機能ブロックについて説明する。
【００２８】
配信制御部４１は、プログラム配信ソフトウェア４０における各機能ブロックの動作をコントロールする。この配信制御部４１の制御に応じて他の各機能ブロックが動作することで、差分データＤＴ４０３や更新データＤＴ１００が生成され、サーバ１０から配信ネットワークを介して各ＥＣＵに配信データＤＴ１０が配信される。
【００２９】
差分データ生成部４２は、記憶部３２に格納された新プログラムデータＤＴ４０２１と旧プログラムデータＤＴ４０２２から、差分データＤＴ４０３を生成する。
【００３０】
データ圧縮部４３は、記憶部３２から読み出した新プログラムデータＤＴ４０２１または差分データＤＴ４０３を圧縮し、更新データＤＴ１００を生成する。このときデータ圧縮部４３は、圧縮入力バッファＢＦ１０１および圧縮出力バッファＢＦ１０２を作業領域として用いて、新プログラムデータＤＴ４０２１または差分データＤＴ４０３の圧縮を行う。なお、データ圧縮部４３によるデータ圧縮処理の詳細については、後で図１２を参照して説明する。
【００３１】
データ配信部４４は、記憶部３２に格納された更新データＤＴ１００を読み出し、これに基づいて配信データＤＴ１０を生成して、データ送受信部４５に出力する。
【００３２】
データ送受信部４５は、データ配信部４４から配信データＤＴ１０が出力されると、その配信データＤＴ１０をＷＡＮ通信装置３５に出力して送信させる。これにより、データ送受信部４５は、ＷＡＮ通信装置３５を用いて、車外ネットワーク２０を介して配信データＤＴ１０を車両１に送信する。
【００３３】
図４は、サーバ１０で動作するデータ圧縮部４３のソフトウェア内部構成例を示すブロック図である。データ圧縮部４３は、圧縮方法切替部７１、差分更新符号化部７２、圧縮更新符号化部７３、および更新データ保存部７４で構成されている。
【００３４】
圧縮方法切替部７１は、更新方式に基づき圧縮方法を切り替える判断部である。配信制御部４１からデータ圧縮の指示を受けると、圧縮方法切替部７１は、記憶部３２からＥＣＵ機能データＤＴ４０１を読み出して、更新対象のＥＣＵが対応している更新方式が差分更新方式と圧縮更新方式のいずれであるかを確認する。そして、確認した更新方式に基づき、差分更新符号化部７２または圧縮更新符号化部７３のいずれを使用するかを選択することで、圧縮方法の切替を行う。なお、更新対象のＥＣＵが対応している更新方式が全更新方式である場合は、更新データＤＴ１００の生成において圧縮が不要であるため、配信制御部４１からデータ圧縮の指示が出力されない。したがって、差分更新符号化部７２および圧縮更新符号化部７３のいずれも選択されない。
【００３５】
差分更新符号化部７２は、更新方式が差分更新方式であるときに、圧縮方法切替部７１により選択されて圧縮符号化の指示を受ける。圧縮符号化の指示を受けると、差分更新符号化部７２は、記憶部３２から差分データＤＴ４０３を読み出し、データの圧縮および符号化を行う。
【００３６】
圧縮更新符号化部７３は、更新方式が圧縮更新方式であるときに、圧縮方法切替部７１により選択されて圧縮符号化の指示を受ける。圧縮符号化の指示を受けると、圧縮更新符号化部７３は、記憶部３２から新プログラムデータＤＴ４０２１を読み出し、データの圧縮および符号化を行う。
【００３７】
更新データ保存部７４は、差分更新符号化部７２によって圧縮符号化された差分データＤＴ４０３、または圧縮更新符号化部７３によって圧縮符号化された新プログラムデータＤＴ４０２１を、更新データＤＴ１００として記憶部３２に保存する。
【００３８】
データ圧縮部４３では、以上説明したような各機能ブロックの動作により、更新方式に応じて圧縮された更新データＤＴ１００が生成される。
【００３９】
図５は、プログラム更新装置１１のハードウェア構成例を示すブロック図である。図５に示すように、プログラム更新装置１１は、マイコン９１、車外通信装置９２、および車内通信装置９３を備える。
【００４０】
マイコン９１は、プログラム更新管理ソフトウェア１０００を動作させるための演算処理装置である。マイコン９１は、揮発性メモリであるＳＲＡＭ９１０１と、不揮発性メモリであるＦＲＯＭ９１０２を内蔵する。車外通信装置９２は、サーバ１０と車外ネットワーク２０を介して接続され、サーバ１０から配信された配信データＤＴ１０を受信してマイコン９１に出力する。車内通信装置９３は、各ＥＣＵと車内ネットワーク２１を介して接続され、サーバ１０から配信されてマイコン９１から出力された配信データＤＴ１０を各ＥＣＵに転送する。これにより、プログラム更新装置１１は、サーバ１０と各ＥＣＵ間のネットワーク中継装置として機能する。
【００４１】
図６は、プログラム更新装置１１のマイコン９１上で動作するプログラム更新管理ソフトウェア１０００の機能構成例を示すブロック図である。なお、本ブロック図は、プログラム更新装置１１が有する機能をその種類ごとに分割された機能ブロックとして記載しているが、各機能ブロックをさらに分割したり、複数の機能ブロックを統合したりしてもよい。また、プログラム更新管理ソフトウェア１０００は、１つのプログラムで実現される必要はなく、２以上のプログラムの組み合せによって実現されてもよい。
【００４２】
プログラム更新管理ソフトウェア１０００は、更新制御部１００１、車外データ送受信部１００２、配信データ受信管理部１００３、配信データ転送部１００４、車内データ送受信部１００５の各機能ブロックを有する。プログラム更新装置１１において、マイコン９１によりプログラム更新管理ソフトウェア１０００が実行されると、これらの機能ブロックがマイコン９１により実現される。すなわち、プログラム更新装置１１は、マイコン９１においてプログラム更新管理ソフトウェア１０００を実行することで、更新制御部１００１、車外データ送受信部１００２、配信データ受信管理部１００３、配信データ転送部１００４、および車内データ送受信部１００５を備えたものとして動作することができる。
【００４３】
プログラム更新管理ソフトウェア１０００により実現されるプログラム更新装置１１の各機能ブロックについて説明する。
【００４４】
更新制御部１００１は、プログラム更新管理ソフトウェア１０００における各機能ブロックの動作をコントロールする。この更新制御部１００１の制御に応じて他の各機能ブロックが動作することで、サーバ１０から配信された配信データＤＴ１０が中継され、各ＥＣＵに転送される。
【００４５】
車外データ送受信部１００２は、車外通信装置９２を介して接続されたサーバ１０から各ＥＣＵ（ＥＣＵ１２等）に向けて送信された配信データＤＴ１０を受信する。
【００４６】
配信データ受信管理部１００３は、車外データ送受信部１００２が受信した各ＥＣＵの配信データＤＴ１０をＦＲＯＭ９１０２に記録する。
【００４７】
配信データ転送部１００４は、ＦＲＯＭ９１０２に格納された配信データＤＴ１０を読み出し、車内データ送受信部１００５に出力してデータ転送指示を出す。
【００４８】
車内データ送受信部１００５は、配信データ転送部１００４から配信データＤＴ１０が出力されると、その配信データＤＴ１０を車内通信装置９３に出力して送信させる。これにより、車内データ送受信部１００５は、車内通信装置９３を用いて、車内ネットワーク２１を介して配信データＤＴ１０を更新対象であるＥＣＵ宛に転送する。
【００４９】
図７は、ＥＣＵ１２のハードウェア構成例を示すブロック図である。図７に示すように、ＥＣＵ１２は、マイコン１１１、専用ＩＣ１１２、およびＣＡＮ通信装置１１３を備えており、センサ１１４およびアクチュエータ１１５と接続されている。なお、他のＥＣＵ１３および１４もＥＣＵ１２と同様の構成であるため、以下ではＥＣＵ１２を代表例として各ＥＣＵの構成を説明する。
【００５０】
マイコン１１１は、プログラム復元ソフトウェア１２００を動作させるための演算処理装置である。マイコン１１１は、揮発性メモリであるＳＲＡＭ１１１１と、不揮発性メモリであるＦＲＯＭ１１１２を内蔵する。専用ＩＣ１１２は、マイコン１１１と協調してＥＣＵ１２の機能を実現するための各種の処理や動作を行う回路であり、たとえばＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ  Ｓｐｅｃｉｆｉｃ  Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔ）などを用いて構成される。センサ１１４は、ＥＣＵ１２の機能を実現するためのセンサ情報を取得してマイコン１１１に出力する。アクチュエータ１１５は、たとえばモータなどを用いて構成され、マイコン１１１の制御に応じて動作する。なお、ＥＣＵ１２は専用ＩＣ１１２を搭載しなくてもよいし、センサ１１４やアクチュエータ１１５が接続されていなくてもよい。ＣＡＮ通信装置１１３は、プログラム更新装置１１や他のＥＣＵと車内ネットワーク２１を介して接続され、プログラム更新装置１１から転送された配信データＤＴ１０を受信したり、他のＥＣＵとの間で車両１の動作に関する様々な情報を送受信したりする。
【００５１】
図８は、ＥＣＵ１２のマイコン１１１上で動作する本発明の第１の実施形態に係るプログラム復元ソフトウェア１２００の機能構成例を示すブロック図である。なお、本ブロック図は、ＥＣＵ１２が有する機能をその種類ごとに分割された機能ブロックとして記載しているが、各機能ブロックをさらに分割したり、複数の機能ブロックを統合したりしてもよい。また、プログラム復元ソフトウェア１２００は、１つのプログラムで実現される必要はなく、２以上のプログラムの組み合せによって実現されてもよい。
【００５２】
プログラム復元ソフトウェア１２００は、復元制御部１２０１、データ送受信部１２０２、配信データ受信管理部１２０３、更新データ解凍部１２０４、新プログラム復元部１２０５の各機能ブロックを有する。ＥＣＵ１２において、マイコン１１１によりプログラム復元ソフトウェア１２００が実行されると、これらの機能ブロックがマイコン１１１により実現される。すなわち、ＥＣＵ１２は、マイコン１１１においてプログラム復元ソフトウェア１２００を実行することで、復元制御部１２０１、データ送受信部１２０２、配信データ受信管理部１２０３、更新データ解凍部１２０４、および新プログラム復元部１２０５を備えたものとして動作することができる。
【００５３】
プログラム復元ソフトウェア１２００により実現されるＥＣＵ１２の各機能ブロックについて説明する。
【００５４】
復元制御部１２０１は、プログラム復元ソフトウェア１２００における各機能ブロックの動作をコントロールする。この復元制御部１２０１の制御に応じて他の各機能ブロックが動作することで、サーバ１０から配信されてプログラム更新装置１１により中継された配信データＤＴ１０を用いて、ＥＣＵ１２のプログラムが更新される。
【００５５】
データ送受信部１２０２は、復元制御部１２０１からの指示に従ってＣＡＮ通信装置１１３を操作し、車内ネットワーク２１を介して接続された他の機器、すなわちプログラム更新装置１１やＥＣＵ１３、１４との間でデータ送受信を行う。プログラム更新装置１１からＥＣＵ１２に配信データＤＴ１０が送信されると、その配信データＤＴ１０は、ＣＡＮ通信装置１１３を用いてデータ送受信部１２０２により受信される。
【００５６】
配信データ受信管理部１２０３は、データ送受信部１２０２が受信した配信データＤＴ１０を、ＳＲＡＭ１１１１上に設けられた受信バッファＢＦ１２０に保存する。
【００５７】
更新データ解凍部１２０４は、受信バッファＢＦ１２０に格納されている配信データＤＴ１０から更新データＤＴ１００を解凍し、ＳＲＡＭ１１１１上に設けられた解凍バッファＢＦ１２１に格納する。
【００５８】
新プログラム復元部１２０５は、更新データ解凍部１２０４で解凍した更新データＤＴ１００を用いて、更新後の新プログラムデータＤＴ１２３の復元を行う。このとき、必要に応じて、既にＦＲＯＭ１１１２に格納されている更新前の旧プログラムデータＤＴ１２２を用いる。そして、復元した新プログラムデータＤＴ１２３をＦＲＯＭ１１１２に保存することで、ＥＣＵ１２のプログラムを更新する。
【００５９】
図９は、本発明の第１の実施形態に係るプログラム更新システムにおけるプログラム更新処理全体の流れを示すシーケンス図である。なお、以下ではＥＣＵ１２のプログラムを更新する場合を代表例として説明するが、他のＥＣＵ１３やＥＣＵ１４のプログラムを更新する場合も同様である。
【００６０】
最初に、サーバ１０は、ステップＳＴ２１において、ＥＣＵ１２に配信する配信データＤＴ１０の元となる更新データＤＴ１００を生成するための更新データ生成処理を行う。なお、この更新データ生成処理の詳細については、後で図１０を参照して説明する。
【００６１】
次に、サーバ１０は、ステップＳＴ２２において、データ配信部４４により、ステップＳＴ２１で生成されて記憶部３２に格納された更新データＤＴ１００に基づいて、配信データＤＴ１０を生成する。そして、データ送受信部４５により、配信データＤＴ１０を車両１に送信する。プログラム更新装置１１は、サーバ１０から配信データＤＴ１０をダウンロードして、プログラム更新装置１１のＦＲＯＭ９１０２に保持する。
【００６２】
その後、プログラム更新装置１１は、ステップＳＴ２３において、ステップＳＴ２２でダウンロードした配信データＤＴ１０をＥＣＵ１２に転送する前処理として、配信データ転送準備処理を行う。ステップＳＴ２３の配信データ転送準備処理が完了すると、プログラム更新装置１１は、続くステップＳＴ２４において、ＥＣＵ１２に対して配信データＤＴ１０を転送するための配信データ転送処理を行う。ステップＳＴ２４で全ての配信データＤＴ１０の転送が完了すると、プログラム更新装置１１は、ステップＳＴ２５において、後処理としての配信データ転送完了処理を実施する。ステップＳＴ２５の処理が終わると、ＥＣＵ１２のプログラム更新処理が完了する。なお、ステップＳＴ２３〜ＳＴ２５の各処理の詳細については、後で図１３を参照して説明する。
【００６３】
ここで、図９のステップＳＴ２１で行われる更新データ生成処理の詳細を説明する。図１０は、ステップＳＴ２１でサーバ１０が実行する更新データ生成処理の流れを示すフロー図である。
【００６４】
ステップＳＴ５０１において、配信制御部４１は、圧縮対象とするデータの確認を行う。具体的には、配信制御部４１は、予め記憶部３２に格納された更新管理データＤＴ４００を読み出し、更新対象のＥＣＵがＥＣＵ１２であることと、ＥＣＵ１２が対応している更新方式とを確認する。
【００６５】
ステップＳＴ５０２において、配信制御部４１は、ステップＳＴ５０１で確認した更新方式が前述の差分更新方式と圧縮更新方式のいずれであったかを判定する。その結果、更新方式が差分更新方式であった場合は、差分データ生成部４２に対して差分データＤＴ４０３の生成を指示し、処理をステップＳＴ５０３に進める。一方、圧縮更新方式であった場合は、データ圧縮部４３に対して新プログラムデータＤＴ４０２１の圧縮を指示し、処理をステップＳＴ５０５に進める。なお、更新方式が差分更新方式と圧縮更新方式のいずれでもない場合、たとえば全更新方式である場合は、データ圧縮が不要であるため、新プログラムデータＤＴ４０２１をそのまま更新データＤＴ１００として保存し、図１０の更新データ生成処理を終了すればよい。また、ＥＣＵ１２が差分更新方式と圧縮更新方式のいずれにも対応している場合は、予めどちらの更新方式を用いるかを決めておき、その更新方式に合わせてステップＳＴ５０２の判定を行えばよい。
【００６６】
ステップＳＴ５０３において、差分データ生成部４２は、配信制御部４１の指示を受けて、記憶部３２に格納されているＥＣＵ１２の新プログラムデータＤＴ４０２１と旧プログラムデータＤＴ４０２２の差分に基づき、差分データＤＴ４０３を生成する。続けて、配信制御部４１は、データ圧縮部４３に対し、差分データ生成部４２が生成した差分データＤＴ４０３のデータ圧縮を指示する。ステップＳＴ５０４において、データ圧縮部４３は、配信制御部４１からの指示を受けて、記憶部３２に格納されている差分データＤＴ４０３のデータ圧縮を行う。このときデータ圧縮部４３は、図４の差分更新符号化部７２を用いて、差分データＤＴ４０３を圧縮する。差分データＤＴ４０３の圧縮が完了したら、処理をステップＳＴ５０６に進める。
【００６７】
ステップＳＴ５０５において、データ圧縮部４３は、配信制御部４１からの指示を受けて、記憶部３２に格納されている新プログラムデータＤＴ４０２１のデータ圧縮を行う。このときデータ圧縮部４３は、図４の圧縮更新符号化部７３を用いて、新プログラムデータＤＴ４０２１を圧縮する。新プログラムデータＤＴ４０２１の圧縮が完了したら、処理をステップＳＴ５０６に進める。
【００６８】
ステップＳＴ５０６において、データ圧縮部４３は、図４の更新データ保存部７４を用いて、ステップＳＴ５０４またはＳＴ５０５で圧縮したデータを、更新データＤＴ１００として記憶部３２に保存する。ステップＳＴ５０６で更新データＤＴ１００の保存が完了したら、図１０の更新データ生成処理を終了する。
【００６９】
図１１は、データ圧縮部４３におけるデータ圧縮を説明する図である。図１１（ａ）は、更新方式が差分更新方式である場合に、図１０のステップＳＴ５０４で行われる差分データＤＴ４０３の圧縮符号化を説明する図である。この場合、データ圧縮部４３において、まず差分更新符号化部７２は、記憶部３２から圧縮元となる差分データＤＴ４０３の一部データ列（参照部ＡＲ８０１と符号化対象部ＡＲ８０２）を読み出し、圧縮入力バッファＢＦ１０１に格納する。なお、ここで圧縮入力バッファＢＦ１０１に格納されるデータ列の範囲を、以下では「スライド窓」と称する。図１１（ａ）のスライド窓ＷＤ１０は、このデータ列の範囲を表している。すなわち、スライド窓ＷＤ１０内の領域は、参照部ＡＲ８０１と符号化対象部ＡＲ８０２とに分けられる。
【００７０】
差分更新方式によるデータ圧縮では、スライド窓ＷＤ１０のサイズは、ＥＣＵ１２においてＳＲＡＭ１１１１上に設けられる解凍バッファＢＦ１２１の容量に合わせて設定される。すなわち、差分更新符号化部７２は、ＥＣＵ１２が解凍バッファＢＦ１２１として使用可能なＳＲＡＭ１１１１の領域のサイズ以内となるように、スライド窓ＷＤ１０のサイズを決定する。なお、解凍バッファＢＦ１２１の容量は、予め記憶部３２に格納されたＥＣＵ機能データＤＴ４０１を参照することで確認できる。
【００７１】
差分更新符号化部７２は、たとえばＬＺ７７等の符号化アルゴリズムを用いて、符号化対象部ＡＲ８０２のデータ列を圧縮符号化する。このとき、参照部ＡＲ８０１のデータ列は、符号化対象部ＡＲ８０２のデータ列を圧縮符号化するための辞書として利用される。具体的には、差分更新符号化部７２は、参照部ＡＲ８０１の中から、符号化対象部ＡＲ８０２のデータ列ともっとも長く一致するデータ列（最長一致列と呼ぶ）を探索する。最長一致列を見つけると、差分更新符号化部７２は、符号化対象部ＡＲ８０２のうちで最長一致列に対応するデータ列を、最長一致列に対するポインタに置き換えて圧縮符号化する。このポインタは、参照部ＡＲ８０１における最長一致列の位置情報やデータ長などの情報を含む。最長一致列が長いほど、圧縮符号化によりデータ量が削減されて圧縮率が高くなる。こうして符号化対象部ＡＲ８０２を圧縮符号化することで生成されたデータ列は、符号化データ列ＡＲ８０４として圧縮出力バッファＢＦ１０２に格納される。なお、圧縮出力バッファＢＦ１０２には、符号化データ列ＡＲ８０４よりも前に圧縮符号化された符号化データ列ＡＲ８０３が既に格納済である。
【００７２】
更新データ保存部７４は、たとえば圧縮出力バッファＢＦ１０２の容量が一杯になったときなどの所定のタイミングにおいて、それまでに圧縮出力バッファＢＦ１０２に蓄積されたデータ列（符号化データ列ＡＲ８０３およびＡＲ８０４）を、更新データＤＴ１００の一部である部分更新データＡＲ８０６として記憶部３２に保存する。なお、記憶部３２には、部分更新データＡＲ８０６よりも前に生成された部分更新データＡＲ８０５が既に格納済みである。
【００７３】
差分更新符号化部７２は、最初にスライド窓ＷＤ１０を差分データＤＴ４０３の先頭に設置して、上記のような圧縮符号化処理および保存処理を行う。その後はスライド窓ＷＤ１０を移動させながら、同様に圧縮符号化処理および保存処理を行う。このようにして、差分データＤＴ４０３の先頭から終端まで、スライド窓ＷＤ１０の移動と圧縮符号化処理および保存処理とを繰り返す。これにより、全ての差分データＤＴ４０３を圧縮符号化して更新データＤＴ１００を生成することができる。
【００７４】
図１１（ｂ）は、更新方式が圧縮更新方式である場合に、図１０のステップＳＴ５０５で行われる新プログラムデータＤＴ４０２１の圧縮符号化を説明する図である。この場合、データ圧縮部４３において、まず圧縮更新符号化部７３は、記憶部３２から圧縮元となる新プログラムデータＤＴ４０２１の一部データ列（参照部ＡＲ８１１、参照部ＡＲ８１２および符号化対象部ＡＲ８１３）を読み出し、圧縮入力バッファＢＦ１０１に格納する。図１１（ｂ）のスライド窓ＷＤ２０は、このとき圧縮入力バッファＢＦ１０１に格納されるデータ列の範囲を表している。すなわち、スライド窓ＷＤ２０内の領域は、参照部ＡＲ８１１、参照部ＡＲ８１２および符号化対象部ＡＲ８１３に分けられる。
【００７５】
圧縮更新方式によるデータ圧縮では、スライド窓ＷＤ２０のサイズは、ＥＣＵ１２においてＳＲＡＭ１１１１上に設けられる解凍バッファＢＦ１２１の容量よりも大きくなるように設定される。すなわち、圧縮更新符号化部７３は、ＥＣＵ１２が解凍バッファＢＦ１２１として使用可能なＳＲＡＭ１１１１の領域のサイズに関わらず、差分更新符号化部７２により設定されるスライド窓ＷＤ１０よりも大きなサイズで、スライド窓ＷＤ２０のサイズを決定する。
【００７６】
参照部ＡＲ８１１は、既に圧縮符号化と記憶部３２への保存がなされている部分更新データＡＲ８１６に対応するデータ列である。参照部ＡＲ８１２は、圧縮符号化済みで記憶部３２には未保存の符号化データ列ＡＲ８１４に対応するデータ列である。これらのデータ列はいずれも、符号化対象部ＡＲ８１３のデータ列を圧縮符号化するための辞書として利用される。すなわち、圧縮更新符号化部７３が圧縮更新方式に従って更新データＤＴ１００を生成する場合には、差分更新符号化部７２が差分更新方式に従って更新データＤＴ１００を生成する場合よりも、圧縮符号化に用いる辞書データの範囲が拡大される。
【００７７】
圧縮更新符号化部７３は、差分更新符号化部７２による圧縮符号化処理と同様に、たとえばＬＺ７７等の符号化アルゴリズムを用いて、符号化対象部ＡＲ８１３のデータ列を圧縮符号化する。具体的には、圧縮更新符号化部７３は、スライド窓ＷＤ２０内の参照部ＡＲ８１１および参照部ＡＲ８１２の中から、符号化対象部８１３のデータ列に対する最長一致列を探索する。そして、符号化対象部８１３のうちで最長一致列に対応するデータ列を、最長一致列に対するポインタに置き換えて圧縮符号化する。こうして符号化対象部ＡＲ８１３を圧縮符号化することで生成されたデータ列は、符号化データ列ＡＲ８１５として圧縮出力バッファＢＦ１０２に格納される。なお、圧縮出力バッファＢＦ１０２には、符号化データ列ＡＲ８１５よりも前に圧縮符号化された符号化データ列ＡＲ８１４が既に格納済である。
【００７８】
圧縮更新符号化部７３は、更新データ保存部７４と同様に、所定のタイミングにおいて、それまでに圧縮出力バッファＢＦ１０２に蓄積されたデータ列（符号化データ列ＡＲ８１４およびＡＲ８１５）を、更新データＤＴ１００の一部である部分更新データＡＲ８１７として記憶部３２に保存する。なお、記憶部３２には、部分更新データＡＲ８１７よりも前に生成された部分更新データＡＲ８１６が既に格納済みである。
【００７９】
圧縮更新符号化部７３は、最初にスライド窓ＷＤ２０を新プログラムデータＤＴ４０２１の先頭に設置して、上記のような圧縮符号化処理および保存処理を行う。その後はスライド窓ＷＤ２０を移動させながら、同様に圧縮符号化処理および保存処理を行う。このようにして、新プログラムデータＤＴ４０２１の先頭から終端まで、スライド窓ＷＤ２０の移動と圧縮符号化処理および保存処理とを繰り返す。これにより、全ての新プログラムデータＤＴ４０２１を圧縮符号化して更新データＤＴ１００を生成することができる。
【００８０】
ここで、新プログラムデータＤＴ４０２１のデータサイズがＥＣＵ１２の解凍バッファＢＦ１２１の容量よりも大きい場合、圧縮更新符号化部７３が圧縮更新方式に従って行う圧縮符号化では、スライド窓ＷＤ２０のサイズが解凍バッファＢＦ１２１の容量よりも大きくなる。その結果、圧縮符号化において最長一致列の検出率が高まると共に、より長い最長一致列の検出が可能であるため、差分更新方式による圧縮符号化と比較して、相対的に圧縮率を高めることができる。
【００８１】
図１２は、図９のステップＳＴ２２でサーバ１０から配信される配信データＤＴ１０の構造例を示す図である。
【００８２】
図１２において、圧縮元データＤＴ６０は、サーバ１０のデータ圧縮部４３が圧縮符号化処理を行う前の元データを表している。この圧縮元データＤＴ６０の内容は、更新方式によって異なる。具体的には、差分更新方式に従ってデータ圧縮部４３が圧縮符号化を行う場合は、差分データＤＴ４０３が圧縮元データＤＴ６０に該当する。一方、圧縮更新方式に従ってデータ圧縮部４３が圧縮符号化を行う場合は、新プログラムデータＤＴ４０２１が圧縮元データＤＴ６０に該当する。
【００８３】
更新データＤＴ１００は、たとえばＬＺ７７等の符号化圧縮アルゴリズムによって圧縮元データＤＴ６０を圧縮符号化したものである。更新データＤＴ１００にヘッダＤＴ１０１が付加されることで、配信データＤＴ１０が構成される。ヘッダＤＴ１０１は、たとえば更新方式ＤＴ６２１、復元後サイズＤＴ６２２等のデータを含む。更新方式ＤＴ６２１は、更新データＤＴ１００を生成する際に用いられた更新方式を示す識別情報であり、具体的には、差分更新方式または圧縮更新方式のいずれかを指定する情報である。なお、さらに全更新方式を指定可能としてもよい。復元後サイズＤＴ６２２は、更新データＤＴ１００から復元される新プログラムデータＤＴ４０２１のデータサイズを示す情報である。なお、更新方式ＤＴ６２１や復元後サイズＤＴ６２２以外の情報をヘッダＤＴ１０１に含めてもよい。
【００８４】
次に、図９のステップＳＴ２３〜ＳＴ２５でそれぞれ行われる配信データ転送準備処理、配信データ転送処理および配信データ転送完了処理の詳細を説明する。図１３は、ステップＳＴ２３〜ＳＴ２５でプログラム更新装置１１およびＥＣＵ１２が実行する配信データ転送準備処理、配信データ転送処理および配信データ転送完了処理の流れを示すシーケンス図である。
【００８５】
＜ＳＴ２３：配信データ転送準備処理＞
最初に、プログラム更新装置１１の配信データ転送部１００４は、ステップＳＴ１３０１において、車内データ送受信部１００５を介して、ＥＣＵ１２に対してデータ転送開始要求を送信する。このデータ転送開始要求には、データフォーマット、送信予定のデータサイズ、送信したデータの書込み先を示す書込み先アドレスなどの情報が含まれる。
【００８６】
ＥＣＵ１２のデータ送受信部１２０２は、プログラム更新装置１１からデータ転送開始要求を受信すると、その旨を配信データ受信管理部１２０３に通知する。この通知を受けると、配信データ受信管理部１２０３は、ステップＳＴ１３０２において、データ送受信部１２０２を介して、受諾応答をプログラム更新装置１１に送信する。この受諾応答には、プログラム更新装置１１が一度に転送可能な配信データＤＴ１０のデータサイズ（ブロックサイズ）などの情報が含まれる。これにより、配信データ転送準備処理が完了する。
【００８７】
＜ＳＴ２４：配信データ転送処理＞
プログラム更新装置１１の配信データ転送部１００４は、ＥＣＵ１２から受諾応答を受信すると、その受諾応答で指定されたブロックサイズに配信データＤＴ１０を分割する。そして、ステップＳＴ１３０３において、車内データ送受信部１００５を介して、分割された配信データＤＴ１０をＥＣＵ１２に対して送信する。
【００８８】
ＥＣＵ１２のデータ送受信部１２０２は、プログラム更新装置１１から分割された配信データＤＴ１０を受信すると、ステップＳＴ１３０４において、その配信データＤＴ１０に含まれる更新データＤＴ１００を解凍して新プログラムデータＤＴ４０２１を復元するための解凍復元処理を実行する。なお、ステップＳＴ１３０４で実行される解凍復元処理の詳細については、後で図１６を参照して説明する。解凍復元処理により復元された新プログラムデータＤＴ４０２１は、ＦＲＯＭ１１１２に記録される。
【００８９】
新プログラムデータＤＴ４０２１のＦＲＯＭ１１１２への書込みが完了すると、ＥＣＵ１２の配信データ受信管理部１２０３は、ステップＳＴ１３０５において、データ送受信部１２０２を介してプログラム更新装置１１に受信応答を送信する。
【００９０】
プログラム更新装置１１とＥＣＵ１２は、配信データＤＴ１０を全て転送し終えるまで、前述のステップＳＴ１３０３からステップＳＴ１３０５までの一連の処理を、繰り返して実行する（ステップＳＴ１３０６）。これにより、配信データ転送処理が完了する。
【００９１】
＜ＳＴ２５：配信データ転送完了処理＞
配信データＤＴ１０を全て転送し終えると、プログラム更新装置１１の配信データ転送部１００４は、ステップＳＴ１３０７において、車内データ送受信部１００５を介して、ＥＣＵ１２に転送完了通知を送信する。
【００９２】
ＥＣＵ１２の配信データ受信管理部１２０３は、プログラム更新装置１１から転送完了通知を受信すると、ステップＳＴ１３０８において、データ送受信部１２０２を介して、プログラム更新装置１１に受諾応答を送信する。これにより、配信データ転送完了処理が完了する。
【００９３】
図１４は、図１３で説明した各処理において、プログラム更新装置１１とＥＣＵ１２の間で送受信されるコマンドのデータ構造例を示す図である。
【００９４】
＜配信データ転送準備処理のコマンド＞
ＣＭＤ１４１は、図１３のステップＳＴ１３０１において、プログラム更新装置１１からＥＣＵ１２に送信されるデータ転送開始要求コマンドである。データ転送開始要求コマンドＣＭＤ１４１は、ＣＭＤ１４１１〜ＣＭＤ１４１４の各コマンドデータを有する。コマンドデータＣＭＤ１４１１は、当該コマンドを識別するためのコマンドＩＤであり、ここにはデータ転送開始要求コマンドであることを示す識別子が設定される。コマンドデータＣＭＤ１４１２は、更新データＤＴ１００が圧縮されたときの更新方式を示す情報であり、更新データＤＴ１００が差分更新方式で圧縮されているか、圧縮更新方式で圧縮されているかなどを示す。コマンドデータＣＭＤ１４１３は、後に続くコマンドデータＣＭＤ１４１４およびコマンドデータＣＭＤ１４１５のデータ長を示す情報である。コマンドデータＣＭＤ１４１４は、送信したデータを書き込む更新対象ブロックの先頭アドレスを示す情報である。コマンドデータＣＭＤ１４１５は、プログラム更新装置１１からＥＣＵ１２に送信する配信データＤＴ１０のサイズを示す情報である。
【００９５】
ＣＭＤ１４２は、図１３のステップＳＴ１３０２において、ＥＣＵ１２からプログラム更新装置１１に送信されるデータ転送開始に対する受諾応答コマンドである。受諾応答コマンドＣＭＤ１４２は、ＣＭＤ１４２１〜ＣＭＤ１４２３の各コマンドデータを有する。コマンドデータＣＭＤ１４２１は、当該コマンドを識別するためのコマンドＩＤであり、ここにはデータ転送開始要求に対する受諾応答コマンドであることを示す識別子が設定される。コマンドデータＣＭＤ１４２２は、コマンドデータＣＭＤ１４２３のデータ長を示す情報である。コマンドデータＣＭＤ１４２３は、プログラム更新装置１１からＥＣＵ１２に一度に連続して送信可能なデータのサイズ（ブロックサイズ）を示す情報である。
【００９６】
＜配信データ転送処理のコマンド＞
ＣＭＤ１４３は、図１３のステップＳＴ１３０３において、プログラム更新装置１１からＥＣＵ１２に送信される配信データ転送コマンドである。配信データ転送コマンドＣＭＤ１４３は、ＣＭＤ１４３１〜ＣＭＤ１４３３の各コマンドデータを有する。コマンドデータＣＭＤ１４３１は、当該コマンドを識別するためのコマンドＩＤであり、ここには配信データ転送コマンドであることを示す識別子が設定される。コマンドデータＣＭＤ１４３２は、配信データ転送コマンドＣＭＤ１４３の送信回数を示すコマンドカウンタであり、コマンドを送信するたびにインクリメントした値が設定される。コマンドデータＣＭＤ１４３３は、転送するデータの本体部分であり、ここには受諾応答コマンドＣＭＤ１４２のコマンドデータＣＭＤ１４２３にて指定されたブロックサイズの値を上限サイズとして、配信データＤＴ１０が分割されたものが設定される。
【００９７】
ＣＭＤ１４４は、図１３のステップＳＴ１３０５において、ＥＣＵ１２からプログラム更新装置１１に送信される受信応答コマンドである。受信応答コマンドＣＭＤ１４４は、ＣＭＤ１４４１〜ＣＭＤ１４４２の各コマンドデータを有する。コマンドデータＣＭＤ１４４１は、当該コマンドを識別するためのコマンドＩＤであり、ここにはデータ転送に対する受信応答コマンドであることを示す識別子が設定される。コマンドデータＣＭＤ１４４２は、配信データ転送コマンドＣＭＤ１４３の受信回数を示すコマンドカウンタであり、ここには受信した配信データ転送コマンドＣＭＤ１４３において、コマンドデータＣＭＤ１４３２に設定されていたのと同じ値が設定される。
【００９８】
なお、図１３で説明したように、ステップＳＴ１３０６では、分割された配信データＤＴ１０の全てがプログラム更新装置１１からＥＣＵ１２に転送されるまで、プログラム更新装置１１とＥＣＵ１２の間で、配信データ転送コマンドＣＭＤ１４３と受信応答コマンドＣＭＤ１４４が複数回繰り返し送受信される。
【００９９】
＜配信データ転送完了処理のコマンド＞
ＣＭＤ１４５は、図１３のステップＳＴ１３０７において、プログラム更新装置１１からＥＣＵ１２に送信される転送完了通知コマンドである。転送完了通知コマンドＣＭＤ１４５は、コマンドデータＣＭＤ１４５１を有する。コマンドデータＣＭＤ１４５１は、当該コマンドを識別するためのコマンドＩＤであり、ここには転送完了通知コマンドであることを示す識別子が設定される。
【０１００】
なお、図１３のステップＳＴ１３０８においてＥＣＵ１２からプログラム更新装置１１に送信される受諾応答コマンドは、ステップＳＴ１３０７でプログラム更新装置１１からＥＣＵ１２に送信される転送完了通知コマンドＣＭＤ１４５と同じコマンド構造を有している。この場合、コマンドデータＣＭＤ１４５１には、転送完了受諾応答コマンドであることを示す識別子が設定される。
【０１０１】
図１５は、配信データＤＴ１０を分割送信する場合の構成例を示す図である。配信データＤＴ１０のデータサイズはたとえば２ＭＢであり、図１５に示すように、たとえば２５６バイトごとに分割されて、転送データＤＴ１５０１や転送データＤＴ１５０２として、プログラム更新装置１１からＥＣＵ１２に送信される。この場合、たとえば転送データＤ１５０１は、配信データＤＴ１０のうちヘッダＤＴ１０１と更新データＤＴ１００の途中までとを含む分割データである。なお、配信データＤＴ１０を分割せずにプログラム更新装置１１からＥＣＵ１２に送信できる場合は、必ずしも分割しなくてもよい。
【０１０２】
次に、図１３のステップＳＴ１３０４で行われる解凍復元処理の詳細を説明する。図１６は、ステップＳＴ１３０４でＥＣＵ１２が実行する解凍復元処理の流れを示すフロー図である。
【０１０３】
ステップＳＴ１６０１において、データ送受信部１２０２は、ＣＡＮ通信装置１１３を介して、図１５の転送データＤ１５０１や転送データＤ１５０２等によりプログラム更新装置１１から分割送信された配信データＤＴ１０を受信する。データ送受信部１２０２により配信データＤＴ１０が受信されたら、配信データ受信管理部１２０３は、受信バッファＢＦ１２０に配信データＤＴ１０を格納し、復元制御部１２０１に配信データＤＴ１０の受信を通知する。この通知を受けると、復元制御部１２０１は、更新データ解凍部１２０４に対して更新データＤＴ１００の解凍を指示する。
【０１０４】
復元制御部１２０１から更新データＤＴ１００の解凍指示を受けると、ステップＳＴ１６０２において、更新データ解凍部１２０４は、受信バッファＢＦ１２０に格納された配信データＤＴ１０を読み込み、ヘッダＤＴ１０１で指定された更新方式が差分更新方式または圧縮更新方式のいずれであるかを確認する。その結果、更新方式が差分更新方式である場合は処理をステップＳＴ１６０３に進め、圧縮更新方式である場合は処理をステップＳＴ１６０６に進める。
【０１０５】
ステップＳＴ１６０３において、更新データ解凍部１２０４は、ＳＲＡＭ１１１１上に解凍バッファＢＦ１２１を設定し、この解凍バッファＢＦ１２１に更新データＤＴ１００を格納する。なお、ＳＲＡＭ１１１１において設定される解凍バッファＢＦ１２１の容量は、図１０のステップＳＴ５０４において差分データＤＴ４０３を圧縮符号化する際に、サーバ１０の差分更新符号化部７２が設定するスライド窓ＷＤ１０のサイズと同等か、それ以上である。そして、解凍バッファＢＦ１２１に格納された更新データＤＴ１００のうちで解凍に用いる参照部を設定し、参照部のデータ列を元に更新データＤＴ１００の解凍を行う。更新データＤＴ１００の解凍が終わると、復元制御部１２０１は、解凍された更新データＤＴ１００すなわち差分データＤＴ４０３を用いた新プログラムデータＤＴ１２３の復元を、新プログラム復元部１２０５に対して指示する。
【０１０６】
復元制御部１２０１から新プログラムデータＤＴ１２３の復元指示を受けると、ステップＳＴ１６０４において、新プログラム復元部１２０５は、差分更新方式による新プログラムデータＤＴ１２３の復元処理を行う。具体的には、新プログラム復元部１２０５は、ＦＲＯＭ１１１２から旧プログラムデータＤＴ１２２を読み出し、これに対して差分データＤＴ４０３を適用することで、旧プログラムデータＤＴ１２２を新プログラムデータＤＴ１２３に変換し、新プログラムデータＤＴ１２３を復元する。続くステップＳＴ１６０５において、新プログラム復元部１２０５は、ステップＳＴ１６０４で復元した新プログラムデータＤＴ１２３をＦＲＯＭ１１１２に保存する。
【０１０７】
ステップＳＴ１６０６において、更新データ解凍部１２０４は、ステップＳＴ１６０３と同様に、ＳＲＡＭ１１１１上に解凍バッファＢＦ１２１を設定し、この解凍バッファＢＦ１２１に更新データＤＴ１００を格納する。そして、解凍バッファＢＦ１２１に格納された更新データＤＴ１００と、既に復元済みでＦＲＯＭ１１１２に保存されている新プログラムデータＤＴ１２３とのそれぞれにおいて、解凍に用いる参照部を設定し、各参照部のデータ列を元に更新データＤＴ１００の解凍を行う。更新データＤＴ１００の解凍が終わると、新プログラム復元部１２０５は、解凍された更新データＤＴ１００すなわち新プログラムデータＤＴ４０２１を、復元された新プログラムデータＤＴ１２３として、ＦＲＯＭ１１１２に保存する。
【０１０８】
ステップＳＴ１６０５またはＳＴ１６０７で新プログラムデータＤＴ１２３がＦＲＯＭ１１１２に保存されると、ステップＳＴ１６０８において、復元制御部１２０１は、全ての新プログラムデータＤＴ１２３を復元済みであるか確認する。その結果、復元が未完了の新プログラムデータＤＴ１２３がある場合は、ステップＳＴ１６０１に戻って次の配信データＤＴ１０を受信し、更新データＤＴ１００の解凍処理および新プログラムデータＤＴ１２３の復元処理を繰り返す。一方、全ての新プログラムデータＤＴ１２３を復元済みの場合は、図１６の解凍復元処理を終了する。
【０１０９】
図１７は、図１６のステップＳＴ１６０３およびＳＴ１６０４において行われる差動更新方式による解凍復元処理を説明する図である。このときＥＣＵ１２では、プログラム更新装置１１に保存されている更新データＤＴ１００の一部が転送データＡＲ１７０１として受信され、受信バッファＢＦ１２０に格納される。なお、受信バッファＢＦ１２０には、転送データＡＲ１７０１よりも前に受信された転送データＡＲ１７０２が既に格納済みである。
【０１１０】
差動更新方式による解凍復元処理では、更新データ解凍部１２０４は、受信バッファＢＦ１２０に格納されている転送データＡＲ１７０１および転送データＡＲ１７０２を復号して差分データＡＲ１７０３を生成し、ＳＲＡＭ１１１１上に設定された解凍バッファＢＦ１２１に格納する。このとき更新データ解凍部１２０４は、解凍バッファＢＦ１２１に格納済みの差分データＡＲ１７０４を参照部に設定する。そして、転送データＡＲ１７０１および転送データＡＲ１７０２のポインタに含まれる位置情報とデータ列の長さの情報から、差分データＡＲ１７０４において対応するデータ列（最長一致列ＡＲ１７０５）を複製し、ポインタと置き換えることで復号を行う。なお、解凍バッファＢＦ１２１には、差分データＡＲ１７０３よりも前に生成された差分データＡＲ１７０４が既に格納済みである。
【０１１１】
差動更新方式による解凍復元処理を行う場合、更新データ解凍部１２０４は、このようにして、ＳＲＡＭ１１１１上の解凍バッファＢＦ１２１に格納済みの差分データＡＲ１７０４を参照部に設定し、転送データＡＲ１７０１および転送データＡＲ１７０２の解凍を行う。これにより、ＦＲＯＭ１１１２を使用せずにＳＲＡＭ１１１１を使用して、更新データＤＴ１００を解凍することができる。
【０１１２】
更新データ解凍部１２０４により差分データＡＲ１７０３を生成できたら、新プログラム復元部１２０５は、解凍バッファＢＦ１２１に格納されている差分データＡＲ１７０３および差分データＡＲ１７０４と、ＦＲＯＭ１１１２に格納されている旧プログラムデータＤＴ１２２とを用いて、新プログラムデータＤＴ１２３を復元する。このとき新プログラム復元部１２０５は、旧プログラムデータＤＴ１２２から、差分データＡＲ１７０３および差分データＡＲ１７０４の範囲に相当するデータ列を読み取り、これらの差分データと結合することで、新プログラムデータＤＴ１２３を復元する。新プログラムデータＤＴ１２３の復元が完了すると、そのデータをＦＲＯＭ１１１２に保存する。
【０１１３】
図１８は、図１６のステップＳＴ１６０６において行われる圧縮更新方式による解凍復元処理を説明する図である。このときＥＣＵ１２では、プログラム更新装置１１に保存されている更新データＤＴ１００の一部が転送データＡＲ１７１１として受信され、受信バッファＢＦ１２０に格納される。なお、受信バッファＢＦ１２０には、転送データＡＲ１７１１よりも前に受信された転送データＡＲ１７１２が既に格納済みである。
【０１１４】
圧縮更新方式による解凍復元処理では、更新データ解凍部１２０４は、受信バッファＢＦ１２０に格納されている転送データＡＲ１７１１および転送データＡＲ１７１２を復号して、新プログラムデータＤＴ１２３の一部である復号データＡＲ１７１３を生成し、ＳＲＡＭ１１１１上に設定された解凍バッファＢＦ１２１に格納する。このとき更新データ解凍部１２０４は、解凍バッファＢＦ１２１に格納済みの復号データＡＲ１７１４と、ＦＲＯＭ１１１２に保存済みの復号データＡＲ１７１５とを参照部に設定する。なお、復号データＡＲ１７１４および復号データＡＲ１７１５も復号データＡＲ１７１３と同様に、新プログラムデータＤＴ１２３の一部である。そして、転送データＡＲ１７１１および転送データＡＲ１７１２のポインタに含まれる位置情報とデータ列の長さの情報から、復号データＡＲ１７１４および復号データＡＲ１７１５において対応するデータ列（第１のポインタが示す解凍バッファＢＦ１２１上の最長一致列ＡＲ１７１６と、第２のポインタが示すＦＲＯＭ１１１２上の最長一致列ＡＲ１７１７と、第３のポインタが示すＦＲＯＭ１１１２上のＡＲ１７１８）を複製し、各ポインタと置き換えることで復号を行う。なお、解凍バッファＢＦ１２１には、復号データＡＲ１７１３よりも前に生成された復号データＡＲ１７１４が既に格納済みである。
【０１１５】
圧縮更新方式による解凍復元処理を行う場合、更新データ解凍部１２０４は、このようにして、ＳＲＡＭ１１１１上の解凍バッファＢＦ１２１に格納済みの復号データＡＲ１７１４と、ＦＲＯＭ１１１２に保存済みの復号データＡＲ１７１５とを参照部に設定し、転送データＡＲ１７１１および転送データＡＲ１７１２の解凍を行う。これにより、ＳＲＡＭ１１１１およびＦＲＯＭ１１１２を使用して、更新データＤＴ１００を解凍することができる。すなわち、既に復元保存してあるＦＲＯＭ１１１２のデータも解凍時の参照部にすることで、差分更新方式による解凍復元処理と比較して高い圧縮率で圧縮符号化された更新データＤＴ１００を、解凍バッファＢＦ１２１のサイズを増やすことなく解凍することができる。
【０１１６】
更新データ解凍部１２０４により復号データＡＲ１７１３を生成できたら、新プログラム復元部１２０５は、解凍バッファＢＦ１２１に格納されている復号データＡＲ１７１３および復号データＡＲ１７１４を、新プログラムデータＤＴ１２３の一部としてＦＲＯＭ１１１２に保存する。
【０１１７】
更新データ解凍部１２０４と新プログラム復元部１２０５は、図１７、１８でそれぞれ説明したようにして、更新データＤＴ１００の解凍と新プログラムデータＤＴ１２３の復元を繰り返し実行する。これにより、差分更新方式による解凍復元処理と圧縮更新方式による解凍復元処理のそれぞれにおいて、全ての新プログラムデータＤＴ１２３を復元することができる。
【０１１８】
以上説明した本発明の第１の実施形態によれば、以下の作用効果を奏する。
【０１１９】
（１）本実施形態のプログラム更新システムは、車外ネットワーク２０、車内ネットワーク２１を介して互いに接続されたサーバ１０とＥＣＵ１２とを備える。サーバ１０は、複数の更新方式のうちいずれかに従って、圧縮された更新データＤＴ１００を生成するデータ圧縮部４３と、配信データＤＴ１０を配信ネットワークを介してＥＣＵ１２に送信するデータ送受信部４５とを備える。配信データＤＴ１０は、更新データＤＴ１００の生成に用いた更新方式を指定する情報を有するヘッダＤＴ１０１と、更新データＤＴ１００とを含む。ＥＣＵ１２は、配信データＤＴ１０を受信するデータ送受信部１２０２と、データ送受信部１２０２により受信された配信データＤＴ１０から更新データＤＴ１００を解凍する更新データ解凍部１２０４と、更新データ解凍部１２０４により解凍された更新データＤＴ１００を用いて、ヘッダＤＴ１０１で指定された更新方式に従って更新後の新プログラムデータＤＴ１２３を復元する新プログラム復元部１２０５とを備える。このプログラム更新システムにおいて、ＥＣＵ１２の更新データ解凍部１２０４は、ヘッダＤＴ１０１で指定された更新方式に基づいて、更新データＤＴ１００を解凍する際の解凍方法を切り替える。このようにしたので、複数の更新方式に対応したＥＣＵ１２のプログラム更新において、揮発性メモリであるＳＲＡＭ１１１１で解凍処理に使用する解凍バッファＢＦ１２１の容量が少なくても、更新データＤＴ１００の圧縮率を高めて、サーバ１０からＥＣＵ１２に送信する更新データＤＴ１００のデータ量を削減することができる。その結果、揮発性メモリの容量が少ないＥＣＵ１２であっても、プログラム更新の高速化が可能となる。
【０１２０】
（２）サーバ１０において更新データＤＴ１００の生成に用いられる更新方式は、更新前の旧プログラムデータＤＴ４０２２と新プログラムデータＤＴ４０２１との差分に基づく差分データＤＴ４０３を圧縮して更新データＤＴ１００を生成する差分更新方式と、新プログラムデータＤＴ４０２１を圧縮して更新データＤＴ１００を生成する圧縮更新方式とを含む。ＥＣＵ１２の更新データ解凍部１２０４は、ヘッダＤＴ１０１で指定された更新方式が差分更新方式である場合は、第１の解凍方式を用いて更新データＤＴ１００を解凍する（図１６のステップＳＴ１６０２、ＳＴ１６０３）。一方、ヘッダＤＴ１０１で指定された更新方式が圧縮更新方式である場合は、第１の解凍方式とは異なる第２の解凍方式を用いて更新データＤＴ１００を解凍する（図１６のステップＳＴ１６０２、ＳＴ１６０６）。このようにしたので、差分更新方式と圧縮更新方式のそれぞれについて、適切な解凍方式を用いて更新データＤＴ１００の解凍を行うことができる。
【０１２１】
（３）ＥＣＵ１２は、揮発性メモリであるＳＲＡＭ１１１１および不揮発性メモリであるＦＲＯＭ１１１２を備えている。第１の解凍方式では、図１７で説明したように、ＦＲＯＭ１１１２を使用せずにＳＲＡＭ１１１１を使用して更新データＤＴ１００を解凍する。一方、第２の解凍方式では、図１８で説明したように、ＳＲＡＭ１１１１およびＦＲＯＭ１１１２を使用して更新データＤＴ１００を解凍する。一方、サーバ１０のデータ圧縮部４３は、図１１で説明したように、圧縮更新方式に従って更新データＤＴ１００を生成する場合には、差分更新方式に従って更新データＤＴ１００を生成する場合よりも、圧縮に用いる辞書データの範囲を拡大する。このようにしたので、ＳＲＡＭ１１１１で解凍処理に使用する容量が少なくても、圧縮更新方式により高い圧縮率で圧縮された更新データＤＴ１００をＥＣＵ１２において解凍することが可能となる。
【０１２２】
（４）配信データＤＴ１０を送信する配信ネットワークは、車両１に設けられた車内ネットワーク２１と、車両１の外部に設けられた車外ネットワーク２０とを含む。ＥＣＵ１２は、車両１に搭載されて車内ネットワーク２１と接続されている。サーバ１０は、車外ネットワーク２０を介して車内ネットワーク２１と通信可能であり、サーバ１０のデータ送受信部４５は、車外ネットワーク２０および車内ネットワーク２１を介して配信データＤＴ１０をＥＣＵ１２に送信する。ＥＣＵ１２は、車内ネットワーク２１を介して配信データＤＴ１０を受信する。このようにしたので、車両１に搭載されたＥＣＵ１２に対して、配信データＤＴ１０を任意のタイミングで容易に送信することが可能となる。
【０１２３】
（第２の実施形態）
本発明における車両搭載ＥＣＵのプログラム更新方法について、第２の実施形態を説明する。なお、本実施形態では、第１の実施形態と共通の部分については、特に必要のない限り説明を省略する。
【０１２４】
図１９は、本発明の第２の実施形態に係るプログラム更新システムの構成例を示すブロック図である。本実施形態のプログラム更新システムは、第１の実施形態で説明したＥＣＵ１２、１３および１４に替えて、ＥＣＵ１５、１６および１７を有している。これらのＥＣＵは、第１の実施形態におけるＥＣＵ１２、１３および１４と比べて、配信データＤＴ１０が転送される前に、プログラム更新装置１１を介して、各ＥＣＵの状態を表すＥＣＵステータスデータＤＴ１８０をサーバ１０にアップロードする処理をさらに実行するものである。
【０１２５】
ＥＣＵステータスデータＤＴ１８０は、各ＥＣＵの状態として、各ＥＣＵにおけるＳＲＡＭ１１１１の状態、たとえばＳＲＡＭ１１１１においてプログラムの更新時に解凍バッファＢＦ１２１として使用可能な容量などの情報を含むデータである。第１の実施形態では、各ＥＣＵがプログラム更新処理時に解凍バッファＢＦ１２１として使用可能なＳＲＡＭ１１１１の容量は固定値として予め定められており、この解凍バッファＢＦ１２１の容量に合わせて、差分更新方式による圧縮符号化で使用されるスライド窓ＷＤ１０のサイズが決められていた。しかしながら、本実施形態では、ＥＣＵ毎のＳＲＡＭ１１１１の容量の違いと、ＥＣＵの状況に応じてＳＲＡＭ１１１１の使用可能容量が異なることとを踏まえて、配信データＤＴ１０が転送される前に、各ＥＣＵのＳＲＡＭ１１１１の使用可能容量をＥＣＵステータスデータＤＴ１８０に含めて、サーバ１０に通知する。サーバ１０では、各ＥＣＵからＥＣＵステータスデータＤＴ１８０により通知されたＳＲＡＭ１１１１の使用可能容量に応じて、スライド窓ＷＤ１０のサイズを決定し、これに合わせて圧縮入力バッファＢＦ１０１のサイズを設定する。
【０１２６】
ＥＣＵ１５、１６および１７はそれぞれ、第１の実施形態において図７に示したＥＣＵ１２と同様の構成を有しており、マイコン１１１は、第１の実施形態で説明したプログラム復元ソフトウェア１２００とは異なるソフトウェアを実行する。以下では、本実施形態においてマイコン１１１が実行するソフトウェアを、プログラム復元ソフトウェア２０００として説明する。
【０１２７】
図２０は、本発明の第２の実施形態に係るプログラム復元ソフトウェア１２００の機能構成例を示すブロック図である。プログラム復元ソフトウェア２０００は、図８で説明した第１の実施形態のプログラム復元ソフトウェア１２００と比べて、さらにＥＣＵステータス送信部２００１を有している。また、更新データ解凍部１２０４に替えて、更新データ解凍部２００２を有している。これ以外の点は、第１の実施形態で説明したプログラム復元ソフトウェア１２００と同じ機能構成である。
【０１２８】
ＥＣＵステータス送信部２００１は、復元制御部１２０１からの指示に従ってＣＡＮ通信装置１１３を操作し、プログラム更新装置１１にＥＣＵステータスデータＤＴ１８０を送信する。なお、プログラム更新装置１１に送信されたＥＣＵステータスデータＤＴ１８０は、プログラム更新装置１１によってサーバ１０に転送される。
【０１２９】
更新データ解凍部２００２は、第１の実施形態で説明した更新データ解凍部１２０４と同様に、受信バッファＢＦ１２０に格納されている配信データＤＴ１０から更新データＤＴ１００を解凍し、ＳＲＡＭ１１１１上に設けられた解凍バッファＢＦ１２１に格納する。このとき、配信データＤＴ１０のヘッダＤＴ１０１で指定された更新方式に基づいて、解凍方法を切り替える。さらに更新データ解凍部２００２は、サーバ１０が更新データＤＴ１００の圧縮符号化を行った際に用いたアルゴリズムやパラメータに応じて、解凍処理に用いるアルゴリズムやパラメータを設定する機能を有する。なお、サーバ１０から各ＥＣＵに対する圧縮符号化のアルゴリズムやパラメータの通知は、これらの情報をヘッダＤＴ１０１に含めることで行うことができる。
【０１３０】
図２１は、本発明の第２の実施形態に係るプログラム更新システムにおけるプログラム更新処理全体の流れを示すシーケンス図である。なお、以下ではＥＣＵ１５のプログラムを更新する場合を代表例として説明するが、他のＥＣＵ１６やＥＣＵ１７のプログラムを更新する場合も同様である。
【０１３１】
最初に、ＥＣＵ１５は、ステップＳＴ１９０において、サーバ１０に対してＥＣＵステータスデータＤＴ１８０をアップロードする。ＥＣＵ１５からアップロードされたＥＣＵステータスデータＤＴ１８０は、サーバ１０において記憶部３２に格納される。
【０１３２】
次に、サーバ１０は、ステップＳＴ２０１において、記憶部３２に格納されたＥＣＵステータスデータＤＴ１８０に基づいて、ＥＣＵ１５に配信する配信データＤＴ１０の元となる更新データＤＴ１００を生成するための更新データ生成処理を行う。この更新データ生成処理において、サーバ１０の配信制御部４１は、ＥＣＵステータスデータＤＴ１８０を読み出して、ＥＣＵ１５におけるＳＲＡＭ１１１１の使用可能容量を確認し、圧縮符号化における圧縮入力バッファＢＦ１０１のサイズを設定する。こうして設定された圧縮入力バッファＢＦ１０１のサイズに応じて、データ圧縮部４３は、スライド窓ＷＤ１０のサイズを設定し、圧縮元データとしての差分データＤＴ４０３を圧縮符号化することで、差分更新方式によるデータ圧縮を行って更新データＤＴ１００を生成する。このとき、第１の実施形態で例示したＬＺ７７等の符号化アルゴリズムに加えて、たとえばＬＺ７８など、より圧縮率の高い他の符号化アルゴリズムを使用してもよい。なお、圧縮更新方式によるデータ圧縮の場合は、第１の実施形態で説明したのと同様の方法で更新データＤＴ１００を生成すればよい。
【０１３３】
ステップＳＴ２０１において更新データＤＴ１００が生成されたら、その更新データＤＴ１００に基づき、第１の実施形態と同様にして、サーバ１０からプログラム更新装置１１に配信データＤＴ１０をダウンロードする。このとき、配信データＤＴ１０のヘッダＤＴ１０１には、更新方式ＤＴ６２１として、サーバ１０側で更新データＤＴ１００の生成に使用した圧縮符号化のアルゴリズムやパラメータ等の情報を含めるようにする。これにより、ＥＣＵ１５において、配信データＤＴ１０から更新データＤＴ１００を解凍できるようにする。
【０１３４】
ステップＳＴ２３以降では、プログラム更新装置１１およびＥＣＵ１５は、第１の実施形態で説明したのと同様の処理をそれぞれ行う。これにより、配信データＤＴ１０を用いてＥＣＵ１５のプログラム更新が行われる。
【０１３５】
以上説明した本発明の第２の実施形態によれば、ＥＣＵ１５は、配信データＤＴ１０の送信元であるサーバ１０に対して、ＥＣＵステータスデータＤＴ１８０を送信することで揮発性メモリであるＳＲＡＭ１１１１の状態を通知するＥＣＵステータス送信部２００１をさらに備える。サーバ１０のデータ圧縮部４３は、ＥＣＵステータス送信部２００１により通知されたＳＲＡＭ１１１１の状態に基づいて、圧縮符号化時の辞書データとしてのスライド窓ＷＤ１０の範囲を設定する。このようにしたので、第１の実施形態で説明したのと同様の作用効果に加えて、さらに、ＥＣＵ１５におけるＳＲＡＭ１１１１の使用状況に応じて、更新データ１００の圧縮率を柔軟に変化させることができる。
【０１３６】
なお、上記の各実施形態において、プログラム更新装置１１を設けずに、サーバ１０から各ＥＣＵに対して配信データＤＴ１０を直接送信してもよい。このようにしても、各実施形態で説明したのと同様の作用効果を奏することができる。
【０１３７】
また、上記の各実施形態では、車両に搭載されたＥＣＵのプログラム更新を行うプログラム更新システムの例を説明したが、本発明はこれに限定されない。ネットワーク接続された様々な制御装置のプログラム更新において、本発明を適用可能である。
【０１３８】
本発明の技術的範囲は上記の各実施形態に限定されるものではなく、本発明の技術的思想の範囲内で、種々の変形例が可能であることはいうまでもない。
【符号の説明】
【０１３９】
１：車両、１０：サーバ、１１：プログラム更新装置、１２，１３，１４，１５，１６，１７：ＥＣＵ、２０：車外ネットワーク、２１：車内ネットワーク、３１：ＣＰＵ、３２：記憶部、３３：表示部、３４：操作入力部、３５：ＷＡＮ通信装置、４０：プログラム配信ソフトウェア、４１：配信制御部、４２：差分データ生成部、４３：データ圧縮部、４４：データ配信部、４５：データ送受信部、９１：マイコン、９１０１：ＳＲＡＭ、９１０２：ＦＲＯＭ、９２：車外通信装置、９３：車内通信装置、１０００：プログラム更新管理ソフトウェア、１００１：更新制御部、１００２：車外データ送受信部、１００３：配信データ受信管理部、１００４：配信データ転送部、１００５：車内データ送受信部、１１１：マイコン、１１１１：ＳＲＡＭ、１１１２：ＦＲＯＭ、１１２：専用ＩＣ、１１３：ＣＡＮ通信装置、１１４：センサ、１１５：アクチュエータ、１２００：プログラム復元ソフトウェア、１２０１…復元制御部、１２０２：データ送受信部、１２０３：配信データ受信管理部、１２０４，２００２：更新データ解凍部、１２０５：新プログラム復元部、２００１：ＥＣＵステータス送信部
【図１】
2018180948.tif 000003
【図２】
2018180948.tif 000004
【図３】
2018180948.tif 000005
【図４】
2018180948.tif 000006
【図５】
2018180948.tif 000007
【図６】
2018180948.tif 000008
【図７】
2018180948.tif 000009
【図８】
2018180948.tif 000010
【図９】
2018180948.tif 000011
【図１０】
2018180948.tif 000012
【図１１】
2018180948.tif 000013
【図１２】
2018180948.tif 000014
【図１３】
2018180948.tif 000015
【図１４】
2018180948.tif 000016
【図１５】
2018180948.tif 000017
【図１６】
2018180948.tif 000018
【図１７】
2018180948.tif 000019
【図１８】
2018180948.tif 000020
【図１９】
2018180948.tif 000021
【図２０】
2018180948.tif 000022
【図２１】
2018180948.tif 000023