(57)【要約】【課題】プログラム更新のための通信量および所要時間を短縮できる車載装置を提供する。【解決手段】車載装置は、取得した更新データに基づいてプログラム更新を行う。車載装置は、プログラムを記憶する記憶部と、更新データに基づいてプログラムを更新する更新制御部とを備え、記憶部はプログラムを分割した複数のセクションに割り当てられた複数の記憶領域を含み、各記憶領域は割り当てられたセクションよりサイズが大きく、各セクションは他のセクションからのアクセスを許容する関数または変数を含む場合、アクセスのためのインターフェースをセクション内の所定の固定位置に含み、他のセクションはインターフェースを介して関数または変数へアクセスし、更新制御部は更新データに基づいてプログラムの更新対象のセクションと更新内容とを特定し記憶部の更新対象のセクションに割り当てられた記憶領域内に更新内容を記憶させることでプログラム更新を行う。【選択図】図２
2020024579.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介して取得した更新データに基づいてプログラムの更新を行う車載装置であって、
前記プログラムを記憶する記憶部と、
前記更新データに基づいて、前記記憶部に記憶されている前記プログラムを更新する更新制御部とを備え、
前記記憶部は、前記プログラムを分割した複数のセクションにそれぞれ割り当てられた複数の記憶領域を含み、各前記記憶領域は、割り当てられた前記セクションよりサイズが大きく前記セクションを記憶した領域と前記セクションを記憶していない未使用領域とを有し、
前記プログラムと前記プログラムの更新後との各バージョンにおいて、各前記セクションは、他の前記セクションからのアクセスを許容する関数または変数を含む場合、前記関数または前記変数へのアクセスのためのインターフェースを、前記セクション内の所定の固定位置に含み、前記他の前記セクションは、前記インターフェースを介して前記関数または前記変数へアクセスし、
前記更新制御部は、前記更新データに基づいて前記プログラムの更新対象の前記セクションと更新内容とを特定し、前記記憶部の、前記更新対象の前記セクションに割り当てられた記憶領域内に、前記更新内容を記憶させることにより前記プログラムの更新を行う、車載装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、車両に搭載され、プログラムの更新が可能な車載装置に関する。
【背景技術】
【０００２】
車両には、例えばＥＣＵ（Electronic Control Unit）と呼ばれる複数の車載装置が搭載されている。このような車載装置は、１つ以上のＣＰＵ等の制御部および制御部が実行する１つ以上のプログラムを格納した記憶部を備える。車載装置の機能向上のため、このようなプログラムを更新することが提案されている。とくに、利便性向上や工数削減のため、整備工場等に行かなくても、車載装置がプログラム更新用のデータである更新データを無線通信によってネットワークを介して外部のサーバー等から受信してプログラムを更新すること（ＯＴＡ（Over the Air）リプログラミング）が提案されている。
【０００３】
このようなＯＴＡリプログラミングにおいては、通信量の低減や記憶部の書き換え量を低減して、所要時間を短縮することが望まれる。そのために、更新データとして、プログラムの更新部分を表す差分データを高度なアルゴリズムを用いて生成し、通信量を低減することが考えられるが、プログラムの修正内容が軽微であっても、関数や変数のアドレスが変化するとプログラムの広い範囲に影響が及んで更新量が多くなり差分データのサイズも大きくなる場合があり、通信量、書き換え量ともに低減効果は限定的である。また差分データから更新プログラムを復元する処理を実行するには、高スペックな制御部が必要となり、コストが増大する。
【０００４】
特許文献１は、記憶部がプログラムを複数のセクタ（セクション）に分割して記憶し、セクタ単位でプログラムを部分的に更新することでプログラム更新の所要時間を短縮する処理装置を開示している。特許文献１においては、更新する可能性の高い実行ファイル（アプリケーション）を同一セクタに集めて、書き換え対象のセクタを低減することをねらっている。また、特許文献１においては、実行ファイル内の関数や変数を、他の実行ファイルがアクセス（呼び出し、参照）するためにこれらの関数や変数のアドレスが必要な場合、これらの実行ファイルとは異なるセクタに配置された参照テーブルを参照することでアドレスを取得する。これにより、他の実行ファイル内にこれらの関数や変数のアドレスを直接記述しないようにして、実行ファイルの更新によってアドレスが変化しても、これにともなう他の実行ファイルの更新を不要にし、書き換え対象のセクタを低減することをねらっている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１５−１３８４６９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、特許文献１の開示する技術では、書き換え対象のセクタの低減を十分図ることは困難である。第１に、実行ファイルの更新の必要性は、一般にいずれの実行ファイルにおいても発生しうるため、更新する可能性の高い実行ファイルを予め特定して同一セクタに集めて配置することは、困難である。第２に、１つの実行ファイルを更新して、そのサイズが変化した場合は、記憶部の記憶領域においてその後ろに連続配置されている他の実行ファイルがある場合はその配置をずらす必要が生じるため、更新のない他の実行ファイルを記憶しているセクタの書き換えも発生する。第３に、参照テーブルを他のセクタに独立して配置しているため、実行ファイルを更新した結果、他の実行ファイルからアクセスする関数や変数のアドレスが変化した場合、参照テーブルの更新も発生し、参照テーブルを記憶しているセクタの書き換えも必要となる。このように、従来、プログラム更新時の更新量や書き換え量の低減には改良の余地があった。
【０００７】
本発明は、上記課題を鑑みてなされたものであり、プログラム更新のための通信量および所要時間を短縮できる車載装置を提供することを目的とする。
【課題を解決するための手段】
【０００８】
上記課題を解決するために、本発明の一局面は、ネットワークを介して取得した更新データに基づいてプログラムの更新を行う車載装置であって、プログラムを記憶する記憶部と、更新データに基づいて、記憶部に記憶されているプログラムを更新する更新制御部とを備え、記憶部は、プログラムを分割した複数のセクションにそれぞれ割り当てられた複数の記憶領域を含み、各記憶領域は、割り当てられたセクションよりサイズが大きくセクションを記憶した領域とセクションを記憶していない未使用領域とを有し、プログラムとプログラムの更新後との各バージョンにおいて、各セクションは、他のセクションからのアクセスを許容する関数または変数を含む場合、関数または変数へのアクセスのためのインターフェースを、セクション内の所定の固定位置に含み、他のセクションは、インターフェースを介して関数または変数へアクセスし、更新制御部は、更新データに基づいてプログラムの更新対象のセクションと更新内容とを特定し、記憶部の、更新対象のセクションに割り当てられた記憶領域内に、更新内容を記憶させることによりプログラムの更新を行う、車載装置である。
【発明の効果】
【０００９】
本発明によれば、プログラムの更新量を低減することによりプログラム更新のための通信量および所要時間を短縮できる車載装置を提供することができる。
【図面の簡単な説明】
【００１０】
【図１】本発明の一実施形態に係るプログラム更新システムの構成例を示す図
【図２】本発明の一実施形態に係るメモリマップと従来例に係るメモリマップとを示す図
【図３】本発明の一実施形態に係るメモリマップと従来例に係るメモリマップとを示す図
【図４】本発明の一実施形態に係るメモリマップと従来例に係るメモリマップとを示す図
【図５】本発明の一実施形態に係るメモリマップと従来例に係るメモリマップとを示す図
【図６】本発明の一実施形態に係るメモリマップと従来例に係るメモリマップとを示す図
【発明を実施するための形態】
【００１１】
（概要）
本発明に係る車載装置は、記憶部の記憶領域において、プログラムをセクションに分割して記憶しており、セクション間に未使用領域が設けられている。また、セクション内の公開関数および公開変数へのインターフェースをセクション自体の固定位置に設ける。これにより、１つのセクションの更新によって、そのセクションのサイズの変化や公開関数および公開変数のアドレスの変化が生じても、他のセクションの記憶領域内の配置アドレスの変化や内容の変化を抑制でき、プログラム更新時の更新量を低減でき、通信量および所要時間を短縮できる。
【００１２】
（実施形態）
以下、本発明の一実施形態について、図面を参照しながら詳細に説明する。
【００１３】
図１に、本実施形態に係るプログラム更新システム１０の構成例を示す。プログラム更新システム１０は、車両１００と、サーバー２００とを備える。車両１００は車載装置１１０と通信部１２０とを含む。車載装置１１０は例えばＥＣＵ（Electronic Control Unit）と呼ばれる、車両の各種制御を行う装置である。車載装置１１０の個数は限定されない。車載装置１１０は、プログラムを記憶する記憶部１１１と、記憶部１１１からプログラムを読み出して実行する１つ以上のＣＰＵ等のプロセッサとを有する。プロセッサは、また、記憶部１１１に記憶されているプログラムを書き換える更新制御部１１２として機能する。通信部１２０はサーバー２００と例えば無線ネットワークを介して通信し、更新データを受信する。通信のタイミングは限定されず、通信部１２０からサーバー２００に更新データがあるか問い合わせて、サーバー２００に更新データがあればサーバー２００に更新データを送信させてもよいし、サーバー２００に更新データがあれば、通信部１２０からの問い合わせがなくても、サーバー２００から通信部１２０に更新データを送信してもよい。更新制御部１１２は通信部１２０が受信した更新データを取得し、更新データに基づいてプログラムの更新位置と更新内容とを特定し、記憶部１１１の更新位置に更新内容を記憶させることによって、記憶部１１１に記憶されているプログラムをその更新版のプログラムである更新プログラムに変更する。車載装置１１０は、以上の他にも車両１００に搭載された機器との間の通信や制御のための入出力部を備えてもよい。
【００１４】
図２に、記憶部１１１の記憶領域における、本実施形態に係るプログラムの記憶態様を示すメモリマップ３００を示す。また、比較のため従来の一例に係るプログラムの記憶態様を示すメモリマップ９００を示す。
【００１５】
プログラムは一例として、ＢＳＰ（Boot Strap Processor）と呼ばれる初期化実行プロセッサ用プログラムおよびＯＳ（Operating System）と呼ばれる基本プログラムとを含むＢＳＰ（ＯＳ）、複数のアプリケーション１、２、３、および、データの各部分に分類される。
【００１６】
従来のメモリマップ９００においては、これらの部分が連続して配置され、さらに、参照テーブルが独立した部分として別領域に配置される。参照テーブルは、例えばアプリケーションが、他のアプリケーションからのアクセスを許可する関数や変数のアドレスを記述したテーブルであり、他のアプリケーションは、参照テーブルを参照することにより、アクセスしたい関数や変数のアドレスを取得し、アドレスを用いて関数や変数にアクセスする。
【００１７】
本実施形態のメモリマップ３００においては、プログラムは、更新前および更新後の各バージョンにおいて、複数のセクションに分割され、分割された部分ごとに未使用領域を隔てて配置される。一例として、プログラムはＢＳＰ（ＯＳ）、複数のアプリケーション１、２、３、および、データの各セクションに分割されて、それぞれが割り当てられた記憶領域に記憶される。各記憶領域のサイズは、各セクションのサイズより大きく、セクションが実際に記憶された領域の後ろに、セクションが記憶されていない未使用領域が存在している。メモリマップ３００においては、参照テーブルを独立したセクションとしては設けず、後述するように各セクション内に、代わりとなるラッパ関数を設ける。
【００１８】
本実施形態において、記憶部１１１の書き換え量の低減について、以下に例を挙げて説明する。
（例１）
本例は、アプリケーション１が更新され、アプリケーション１のサイズが大きくなった場合の例である。本例では、アプリケーション１内に公開関数や公開変数が存在しないか、あるいは、存在するがアドレスに変化がないものとする。図３に、本例における従来のメモリマップ９００と本実施形態のメモリマップ３００とについて、プログラム更新のための書き換え対象となる部分を斜線で示す。従来のメモリマップ９００においては、アプリケーション１のサイズが大きくなった分、アプリケーション１の後ろに連続して配置されているアプリケーション２、３およびデータの配置アドレスが後ろにずれる。そのため、内容が更新されたアプリケーション１だけでなく、更新されていないアプリケーション２、３およびデータの書き換えが発生する。
【００１９】
これに対して、本実施形態のメモリマップ３００においては、アプリケーション１のサイズが大きくなっても、アプリケーション１に割り当てられた記憶領域内に未使用領域があるため、サイズの増加分を未使用領域に記憶させることによって、その記憶領域内にアプリケーション１を記憶させることができる。これにより、他のアプリケーション２、３およびデータの配置アドレスにずれが発生しない。そのためアプリケーション１のみ書き換えが発生する。このように、従来例に比べて記憶部１１１の書き換え量を低減できる。
【００２０】
（例２）
本例は、アプリケーション２が更新され、アプリケーション２のサイズが大きくなった場合の例である。本例では、アプリケーション２内に公開関数や公開変数が存在しないか、あるいは、存在するがアドレスに変化がないものとする。図４に、本例における従来のメモリマップ９００と本実施形態のメモリマップ３００とについて、プログラム更新のための書き換え対象となる部分を斜線で示す。従来のメモリマップ９００においては、アプリケーション２のサイズが大きくなった分、アプリケーション２の後ろに連続して配置されているアプリケーション３およびデータの配置アドレスが後ろにずれる。そのため、内容が更新されたアプリケーション２だけでなく、更新されていないアプリケーション３およびデータの書き換えが発生する。例１の場合に比べて、更新によってサイズが変化したアプリケーションの位置がメモリマップ上で後ろの位置にあるため、例１の場合よりは影響が小さく、書き換え量を小さくできる。しかし、更新対象のアプリケーションを事前に予測することは困難であり、更新対象となるアプリケーションを予めメモリマップ上なるべく後ろに配置することで書き換え量を低減することには限界がある。
【００２１】
これに対して、本実施形態のメモリマップ３００においては、アプリケーション２のサイズが大きくなっても、アプリケーション２に割り当てられた記憶領域内に未使用領域があるため、サイズの増加分を未使用領域に記憶させることによって、その記憶領域内にアプリケーション２を記憶させることができる。これにより、他のアプリケーション３およびデータの配置アドレスにずれが発生しない。そのためアプリケーション２のみ書き換えが発生する。このように、記憶部１１１の書き換え量を低減できる。また、更新対象のアプリケーションがメモリマップ上どの位置にあっても、他のアプリケーション等の配置への影響がない。
【００２２】
（例３）
本例は、アプリケーション１が更新され、アプリケーション１のサイズに変化はないが、アプリケーション１内の公開関数である関数Ａのアドレスが変化した場合の例である。図５に、本例における従来のメモリマップ９００と本実施形態のメモリマップ３００とについて、プログラム更新のための書き換え対象となる部分を斜線で示す。従来のメモリマップ９００においては、更新されたアプリケーション１が書き換え対象となるのみでなく、関数Ａのアドレスが変化したため、関数Ａのアドレスを記述した関数Ａ用テーブルを含む参照テーブルが更新され、書き換え対象となる。
【００２３】
これに対して、本実施形態のメモリマップ３００においては、参照テーブルを独立的に設けない。アプリケーション１は、関数Ａを他のアプリケーションからアクセス可能にする関数Ａ用のラッパ関数を、アプリケーション１内の所定の固定位置に保持している。関数Ａ用のラッパ関数は、関数Ａのアドレスを内部に保持している。他のアプリケーションは、アプリケーション１内の予め定められている固定アドレスに配置されたインターフェースであるラッパ関数を呼び出すことで、関数Ａのアドレスが不明であっても関数Ａを間接的に呼び出すことができる。関数Ａのアドレスが変化した場合、アプリケーション１内の関数Ａのラッパ関数を更新すればよく、更新対象はアプリケーション１のみとなる。他のアプリケーションも同様に公開関数や公開変数へのアクセス用のラッパ関数をアプリケーション内の固定位置に保持しており、公開関数や公開変数のアドレスが変化しても、更新対象はそのアプリケーションのみとなる。このように、従来例に比べて更新対象が減り、記憶部１１１の書き換え量を低減できる。
【００２４】
（例４）
本例は、アプリケーション２が更新され、アプリケーション２のサイズに変化はないが、アプリケーション２内の公開変数である変数Ｃのアドレスが変化した場合の例である。図６に、本例における従来のメモリマップ９００と本実施形態のメモリマップ３００とについて、プログラム更新のための書き換え対象となる部分を斜線で示す。従来のメモリマップ９００においては、更新されたアプリケーション２が書き換え対象となるのみでなく、変数Ｃのアドレスが変化したため、変数Ｃのアドレスを記述した変数Ｃ用テーブルを含む参照テーブルが更新され、書き換え対象となる。
【００２５】
これに対して、本実施形態のメモリマップ３００においては、参照テーブルを独立的に設けない。アプリケーション２は、変数Ｃを他のアプリケーションからアクセス可能にする変数Ｃ用のラッパ関数を、アプリケーション２内の所定の固定位置に保持している。変数Ｃ用のラッパ関数は、変数Ｃのアドレスを内部に保持している。他のアプリケーションは、アプリケーション２内の予め定められている固定アドレスに配置されたインターフェースであるラッパ関数を呼び出すことで、変数Ｃのアドレスが不明であっても変数Ｃを間接的に参照することができる。変数Ｃのアドレスが変化した場合、アプリケーション２内のラッパ関数を更新すればよく、更新対象はアプリケーション２のみとなる。他のアプリケーションも同様に公開関数や公開変数へのアクセス用のラッパ関数をアプリケーション内の固定位置に保持しており、公開関数や公開変数のアドレスが変化しても、更新対象はそのアプリケーションのみとなる。このように、従来例に比べて更新対象が減り、記憶部１１１の書き換え量を低減できる。
【００２６】
なお、例３、例４において、各アプリケーション内の固定位置に設けるのであれば、インターフェースの実装態様に限定はなく、ラッパ関数の代わりに例えば関数Ａや変数Ｃのアドレスを記述した参照テーブルを設けてもよい。
【００２７】
以上の各例において、各セクションに割り当てられた記憶領域は、今後の更新において想定されるセクションごとの最大サイズ以上となるよう、余裕をもって未使用領域を設けておくことが好ましい。また、未使用領域に対しては、特段の処理をしなくてもよいし、ゼロパディング等所定のデータを記憶させる処理をしてもよい。また、プログラムの分割単位は限定されず、例えば１つのアプリケーションを複数のセクションに分割してもよい。
【００２８】
（作用、効果）
以上のように、本実施形態においては、アプリケーションの更新によって、そのサイズが変化したり、その内部の公開関数や公開変数のアドレスが変化したりした場合に、他のアプリケーション等への影響を、メモリマップ上の配置順序にかかわらずなくすことができる。そのため更新対象となる可能性が高いアプリケーション等を特定できなくても、記憶部１１１への書き換え量を低減できる。これにより、記憶部１１１の書き換え時間を低減し、プログラム更新の時間短縮を図ることができる。また、更新対象がアプリケーションでなく、ＢＳＰ（ＯＳ）やデータのセクションであっても同様である。
【００２９】
更新制御部１１２がサーバー２０から取得する更新データは、例えば更新対象のセクションと更新内容とを表すデータとすることができる。本実施形態では、更新データのサイズを小さくすることができるので、高度なアルゴリズムを用いなくても通信量を低減することができる。また、このような形式の更新データであれば、更新制御部１１２は、更新対象のセクションと更新内容とを特定して、記憶部１１１の対象セクションに割り当てられた記憶領域に更新内容を記憶させる制御を、比較的低負荷の処理によって実行することができるので、高スペックな制御部は不要であり、コスト増大を抑制することができる。なお更新制御部１１２は、このようなプログラム更新処理を、プログラムを実行することで行ってもよい。更新処理用のプログラムは、更新対象である上述のプログラムに含まれていてもよいし、別に用意されていてもよい。
【００３０】
以上、本発明の一実施形態を説明したが、本発明は、車載装置、プログラム更新システム、更新制御部が実行するプログラムの更新方法、更新方法を実行させるプログラムを記憶したコンピューター読み取り可能な非一時的な記録媒体、あるいは車載装置を搭載した車両として捉えることができる。
【産業上の利用可能性】
【００３１】
本発明は、車両等に搭載されるプログラムの更新が可能な車載装置に有用である。
【符号の説明】
【００３２】
１０    プログラム更新システム
１００    車両
１１０    車載装置
１１１    記憶部
１１２    更新制御部１１２
１２０    通信部
２００    サーバー
【図１】
2020024579.tif 000003
【図２】
2020024579.tif 000004
【図３】
2020024579.tif 000005
【図４】
2020024579.tif 000006
【図５】
2020024579.tif 000007
【図６】
2020024579.tif 000008