JP7323569B2 - 車載ソフトウェア更新方法および車載システム - Google Patents

Description

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

近年の車両においては、無線通信を利用して車載システムのソフトウェアを更新するＯＴＡ（Over The Air）ソフトウェア更新システムの採用が試みられている。
例えば、特許文献１の車載システムは、無線通信によりクラウドと接続し、プログラムやデータを取得できるように構成されている。また、車載システムの書き換えノードのメモリに、制御用記憶領域、第１蓄積専用領域、第２蓄積専用領域などが存在することが示されている。

また、特許文献２においては、現行バージョンプログラムを格納するための主格納エリアと、更新バージョンプログラムを格納するための副格納エリアとが形成されていることが開示されている。

特開２０１９－７３１０６号公報 特開２００６－３０１９６０号公報

ところで、近年の車載システムには多数の電子制御ユニット（ＥＣＵ）が搭載されており、それぞれのＥＣＵが制御用の独立したコンピュータを内蔵している。したがって、例えば車載システムに新たな機能を追加したり、車載システム全体の性能を向上させるためにソフトウェアの更新（アップデート）を行うような場合には、多数のＥＣＵのそれぞれのコンピュータが利用するソフトウェアをそれぞれ更新する必要がある。

したがって、更新が必要なソフトウェアのデータ量は膨大になり、更新の処理にも膨大な時間がかかることが予想される。また、特許文献１の車載システムでは、書き換えノードのそれぞれに、更新用のプログラムやデータを蓄積するためのメモリに記憶領域を確保しなければならない。
つまり、ソフトウェアの更新を可能にするために容量の大きい専用の記憶領域をＥＣＵ毎にそれぞれ用意しなければならない。また、システム全体ではかなり膨大な記憶容量が必要になる。

しかしながら、更新用ソフトウェアの保存などの目的で用意された記憶領域は更新処理を行う時以外は使用されないので、ソフトウェア更新のために大容量の記憶領域を確保することはシステム全体のメモリ利用効率低下に繋がり、コスト増の要因になる。

また、ソフトウェアの更新がいつまでも完了しないような異常な状況が発生する可能性もある。例えば、１つのソフトウェア更新が完了する前に、車載バッテリなどの電源電圧が低下した場合や、更新が許可された状態でなくなった場合は、更新を中断しなければならない。また、ソフトウェア自身の不具合などに起因して更新を完了できない可能性もある。そして、中断などに起因してソフトウェアの更新を完了できなかった場合には、次回の更新が可能になった時に、同じ更新処理を最初から実行しなければならない。

本発明は、上述した事情に鑑みてなされたものであり、その目的は、ソフトウェア更新に伴って必要とされる記憶領域の容量を削減することが可能な車載ソフトウェア更新方法および車載システムを提供することにある。

前述した目的を達成するために、本発明に係る車載ソフトウェア更新方法および車載システムは、下記（１）～（５）を特徴としている。
（１） 最上位制御部と、その下流に接続されたゾーン制御部と、その下流に接続された複数の下位制御部とを有する車載システムに含まれるソフトウェアを更新するための車載ソフトウェア更新方法であって、
前記ゾーン制御部上のメモリに、前記ゾーン制御部及び前記下位制御部を更新対象とする１つの更新用データを格納可能な第１領域を予め確保し、
所定のソフトウェア供給元に存在する更新用データの有無を繰り返し確認し、
第１のダウンロード条件を満たす更新用データが存在する場合に、前記更新用データを前記ソフトウェア供給元からダウンロードして前記第１領域に格納すると共に、前記第１のダウンロード条件を満たす複数の更新用データが同時に存在する場合には、前記複数の更新用データの中で優先順位の高いものを優先的に選択してダウンロードを実施する、
車載ソフトウェア更新方法。

（２） 最上位制御部と、その下流に接続されたゾーン制御部と、その下流に接続された複数の下位制御部とを有する車載システムであって、
前記ゾーン制御部上のメモリが、前記ゾーン制御部および前記複数の下位制御部のいずれか１つのソフトウェアを更新するために必要な１つの更新用データを格納可能な第１領域を有し、
前記ゾーン制御部が、
前記第１領域に格納する更新用データの更新対象を選択する更新対象選択部と、
所定のソフトウェア供給元に存在する更新用データの有無および更新対象を確認する更新制御部と、
を備え、前記更新制御部は、第１のダウンロード条件を満たす更新用データが存在する場合に、前記更新用データを前記ソフトウェア供給元からダウンロードして前記第１領域に格納すると共に、前記第１のダウンロード条件を満たす複数の更新用データが同時に存在する場合には、前記複数の更新用データの中で優先順位の高いものを優先的に選択してダウンロードを実施する、
車載システム。

（３） 前記更新制御部は、自車両のイグニッション信号がオンの時に更新用データの確認およびダウンロードを実施して前記第１領域へ更新用データを格納し、前記イグニッション信号がオフに切り替わった後で、前記第１領域に格納されている更新用データを利用して更新対象の制御部のソフトウェア更新を実行する、
上記（２）に記載の車載システム。

（４） 前記更新制御部は、前記ソフトウェア供給元に、前記ゾーン制御部を更新対象とする第１の更新用データと、前記下位制御部を更新対象とする第２の更新用データとが同時に存在する場合には、前記第１の更新用データを優先的に選択する、
上記（２）又は（３）に記載の車載システム。

（５） 前記更新制御部は、前記ソフトウェア供給元に複数の更新用データが同時に存在する場合には、複数の中で更新処理の試行回数がより少ない更新用データを優先的に選択する、
上記（２）乃至（４）のいずれかに記載の車載システム。

上記（１）の構成の車載ソフトウェア更新方法によれば、ゾーン制御部、及び複数の下位制御部のいずれを対象としてソフトウェア更新する場合でも、ダウンロードした更新用データの格納先を第１領域に固定することができる。したがって、ソフトウェア更新のために必要な記憶領域を第１領域以外に確保する必要がない。つまり、第１領域を全ての更新対象が共通に利用できるので、複数の下位制御部のいずれにも更新用データを格納するための特別な記憶領域を用意する必要がなく、システム全体のメモリ領域を効率よく利用できる。また、複数の更新用データが同時に存在する場合には、優先順位の高い更新用データだけを優先的に選択してダウンロードするので、第１領域の記憶容量を削減できる。また、更新の失敗などに起因して同じ更新対象の更新用データが繰り返しダウンロードされるような状況を避けることが可能になる。

上記（２）の構成の車載システムによれば、ゾーン制御部、及び複数の下位制御部のいずれを対象としてソフトウェア更新する場合でも、ダウンロードした更新用データの格納先を第１領域に固定することができる。したがって、ソフトウェア更新のために必要な記憶領域を第１領域以外に確保する必要がない。つまり、第１領域を全ての更新対象が共通に利用できるので、複数の下位制御部のいずれにも更新用データを格納するための特別な記憶領域を用意する必要がなく、システム全体のメモリ領域を効率よく利用できる。また、複数の更新用データが同時に存在する場合には、優先順位の高い更新用データだけを優先的に選択してダウンロードするので、第１領域の記憶容量を削減できる。また、更新の失敗などに起因して同じ更新対象の更新用データが繰り返しダウンロードされるような状況を避けることが可能になる。

上記（３）の構成の車載システムによれば、更新用データの確認およびダウンロードを実施する時には、車両の発電機（オルタネータ）から出力される電力を利用できるので、車載バッテリの消耗を考慮する必要がなくなる。したがって、必要な全てのＥＣＵ及び通信機能をフルに利用できる状態に電源を制御することができ、効率よくダウンロードを実施できる。また、ソフトウェア更新を実行する時には、多数のＥＣＵの多くが動作休止状態になるのでソフトウェアの更新に影響を及ぼすような状況が生じにくい。したがって、効率よくソフトウェア更新を実行できる。

上記（４）の構成の車載システムによれば、ゾーン制御部と１つ以上の下位制御部のそれぞれを更新するための更新用データが存在する場合に、ゾーン制御部の更新を先に行うことができる。これにより、最新のソフトウェアに更新されたゾーン制御部の制御下で、これ以降のソフトウェア更新処理を安定した状態で行うことが可能になる。

上記（５）の構成の車載システムによれば、同じ更新用データについてダウンロード及び更新処理の開始がループ状に繰り返されるような異常な状況の発生を避けることができる。また、例えばデータサイズが大きくて時間切れで更新が中断しやすいような更新用データについては処理の順序が後回しになり、短時間で更新可能な更新用データの処理を効率よく行うことが可能になる。

本発明の車載ソフトウェア更新方法および車載システムによれば、ソフトウェア更新に伴って必要とされる記憶領域の容量を削減できる。すなわち、ゾーン制御部、及び複数の下位制御部のいずれを対象としてソフトウェア更新する場合でも、ダウンロードした更新用データの格納先が第１領域だけに固定されるので、ソフトウェア更新のために必要な記憶領域を第１領域以外に確保する必要がない。

以上、本発明について簡潔に説明した。更に、以下に説明される発明を実施するための形態（以下、「実施形態」という。）を添付の図面を参照して通読することにより、本発明の詳細は更に明確化されるであろう。

図１は、本発明の実施形態に係る車載システムの主要部の構成を示すブロック図である。 図２は、図１とは異なる状態の車載システムを示すブロック図である。 図３は、イグニッションオンの状態におけるゾーンＥＣＵの動作を示すフローチャートである。 図４は、イグニッションオフの状態におけるゾーンＥＣＵの動作を示すフローチャートである。

本発明に関する具体的な実施形態について、各図を参照しながら以下に説明する。

＜車載システムの構成＞
図１は、本発明の実施形態に係る車載システム１０の主要部の構成を示すブロック図である。また、図２は、図１とは異なる状態の車載システム１０を示すブロック図である。

図１に示した車両１７に搭載されている車載システム１０は、セントラルＥＣＵ１１、ゾーンＥＣＵ１２、末端ＥＣＵ１３、スマートアクチュエータ１４などを備えている。セントラルＥＣＵ１１とゾーンＥＣＵ１２との間は通信線１８で接続され、ゾーンＥＣＵ１２と末端ＥＣＵ１３及びスマートアクチュエータ１４との間は通信線１９で接続されている。

なお、実際の車両においては同じ車両１７上に複数のゾーンが形成され、ゾーン毎にそれぞれ独立したゾーンＥＣＵ１２が配置される。つまり、セントラルＥＣＵ１１は複数のゾーンＥＣＵ１２と接続される。また、ゾーンは例えば同じ車両１７上の空間における左右などの場所の違いを表す複数の区域として割り当てられる場合もあるし、機能上のグループの違いを表す複数の区域として割り当てられる場合もある。

セントラルＥＣＵ１１は、複数のゾーンを含む車載システム１０全体を統合して管理すると共に、無線通信機能を利用して車両外のインターネットなどの通信網と安全に接続するためのゲートウェイの機能も有している。

したがって、図１に示したゾーンＥＣＵ１２は、この車両１７上で最上位に位置するセントラルＥＣＵ１１の下流側に接続されている。また、ゾーンＥＣＵ１２はその下流側に接続された末端ＥＣＵ１３及びスマートアクチュエータ１４を管理している。

セントラルＥＣＵ１１、ゾーンＥＣＵ１２、及び末端ＥＣＵ１３は、それぞれ独立した制御が可能なマイクロコンピュータ及び通信機能を内蔵している。また、スマートアクチュエータ１４はアクチュエータの機能をソフトウェアにより変更する機能及び通信機能を有している。

したがって、図１に示したゾーンＥＣＵ１２、末端ＥＣＵ１３、及びスマートアクチュエータ１４は、それぞれが自身の動作に必要なプログラムやデータにより構成されるソフトウェアを備えている。また、それぞれのソフトウェアは例えば不揮発性メモリ上に配置することにより書き換え可能な状態になっている。そのため、それぞれのソフトウェアを必要に応じて更新（アップデート）することができる。本実施形態では、これらのソフトウェア更新（ＳＵ）は、無線通信を利用したＯＴＡ（Over The Air）として行うことができる。

図１に示した車載システム１０においては、ゾーンＥＣＵ１２がそれ自身が使うソフトウェアの更新と、末端ＥＣＵ１３及びスマートアクチュエータ１４のそれぞれが使うソフトウェアの更新とを全て管理するようになっている。また、ゾーンＥＣＵ１２は、アップデート専用（ＯＴＡ ＳＵ用）メモリ領域１２ａを備えている。そして、末端ＥＣＵ１３及びスマートアクチュエータ１４のいずれも、アップデート用のメモリ領域を備えていない。

したがって、図１の車載システム１０においてはゾーンＥＣＵ１２上の１つのアップデート専用メモリ領域１２ａを、更新対象が異なる複数種類の更新データを処理するために共通の記憶領域として利用する。つまり、ゾーンＥＣＵ１２自身が使うソフトウェアと、末端ＥＣＵ１３及びスマートアクチュエータ１４のそれぞれが使うソフトウェアを、いずれも共通のアップデート専用メモリ領域１２ａを利用して更新する。

アップデート専用メモリ領域１２ａのために予め確保しておく記憶容量は、全ての種類の更新データの中でデータ容量が最大の１つの更新データを記憶できる大きさに決定される。したがって、例えば比較的容量が小さい更新データであれば、複数種類の更新データを同時にアップデート専用メモリ領域１２ａ上に格納することも可能であるが、容量が大きい更新データは同時に複数を格納することができない。

図１の車両１７において、車載システム１０が動作するために必要とする電源電力は、車両１７に備わっている車載バッテリ１５及びオルタネータ１６から供給できる。但し、エンジンが停止するとオルタネータ１６の発電が止まるので、車両１７が駐車しているような場合には車載バッテリ１５に蓄積されている電力だけしか利用できない。

また、車載バッテリ１５が異常に消耗したような場合には、車載バッテリ１５からの電力供給が制限される可能性がある。オルタネータ１６が動作しているかどうかはイグニッションのオンオフにより識別できる。図１に示したゾーンＥＣＵ１２は、車両１７側から出力されるイグニッション信号ＳＧ－ＩＧを監視することで、イグニッションのオンオフを識別する。

本実施形態の車載システム１０では、各部のソフトウェアを更新するための更新データの供給元としてクラウド２０が用意されている。このクラウド２０は、例えば所定のデータセンタのサーバ上に配置される。このクラウド２０は、車載システム１０のソフトウェア更新のために必要な更新データを提供する機能を有している。

したがって、ゾーンＥＣＵ１２用のソフトウェア、末端ＥＣＵ１３用のソフトウェア、及びスマートアクチュエータ１４用のソフトウェアのそれぞれを更新するための準備ができている場合には、図１に示すようにクラウド２０上に更新対象のそれぞれに対応したアップデートプログラム３１、３２、及び３３が格納されている。

図１の状態において、車載システム１０は３つのアップデートプログラム３１、３２、及び３３をそれぞれ無線データ通信２５によりダウンロードして取得することが可能である。但し、ダウンロードした更新データを記憶する場所が、車載システム１０上にはアップデート専用メモリ領域１２ａだけしか存在しない。

そのため、実際のアップデート専用メモリ領域１２ａの使用状況などを確認しながら、優先順位も考慮しながら適切に各々の更新データのダウンロード及びアップデートを処理する必要がある。本実施形態では、車載システム１０の中でゾーンＥＣＵ１２が主体となってこのような処理を制御する。

通常、無線データ通信２５により容量の大きい更新データをダウンロードする際には、車載システム１０の各部が長い時間に亘って比較的大きな電源電力を消費することが予想される。したがって、本実施形態では車両１７のイグニッションがオンの時に各更新データのダウンロードを実施する。

一方、ダウンロード済みの更新データを使用して車載システム１０上のソフトウェアを実際に更新する際には、更新対象とは無関係の他のＥＣＵからの割り込みなどの影響を受けにくくすることが望ましい。また、ソフトウェアを実際に更新する際には、更新対象とは無関係の他のＥＣＵの動作を制限してシステム全体の消費電力を抑制することが可能である。したがって、本実施形態の車載システム１０は、車両１７のイグニッションがオフの時にソフトウェアの更新を実行する。

図１に示した状況では、クラウド２０上に３種類のアップデートプログラム３１、３２、及び３３が存在するが、本実施形態では更新対象がゾーンＥＣＵ１２であるアップデートプログラム３１の優先順位が他よりも高い。したがって、ゾーンＥＣＵ１２は、最初にアップデートプログラム３１のみを無線データ通信２５によりダウンロードする。その結果、クラウド２０上のアップデートプログラム３１と同じそのコピーであるアップデートプログラム３１Ａがアップデート専用メモリ領域１２ａに格納される。

また、図１に示すように、アップデート専用メモリ領域１２ａにアップデートプログラム３１Ａが格納されている時には、ゾーンＥＣＵ１２のアップデート処理部１２ｂがアップデートプログラム３１Ａをアップデート専用メモリ領域１２ａから読み込んでその更新処理を実行し、これをゾーンＥＣＵ１２自身に更新インストールする。

図１に示した車載システム１０において、アップデートプログラム３１Ａの更新インストールが正常に完了した場合には、アップデート専用メモリ領域１２ａ上のアップデートプログラム３１Ａは不要になる。その場合は、ゾーンＥＣＵ１２がアップデート専用メモリ領域１２ａを開放する。

これにより、アップデート専用メモリ領域１２ａが空き状態になり、この記憶領域を再び利用できる状態になる。そのため、ゾーンＥＣＵ１２は、クラウド２０上にある優先順位の低いアップデートプログラム３２又は３３をダウンロードしてアップデート専用メモリ領域１２ａに格納することができる。また、アップデートプログラム３２及び３３の容量が比較的小さい場合には、それらの両方を同時にアップデート専用メモリ領域１２ａに格納することも可能である。

図２に示した状態においては、ゾーンＥＣＵ１２が無線データ通信２５によりクラウド２０からダウンロードした結果として、クラウド２０上のアップデートプログラム３２と同じコピーであるアップデートプログラム３２Ａがアップデート専用メモリ領域１２ａに格納されている。また、アップデートプログラム３３と同じコピーであるアップデートプログラム３３Ａも同時にアップデート専用メモリ領域１２ａに格納されている。

したがって、図２に示したアップデート処理部１３ａは、ゾーンＥＣＵ１２内のアップデート専用メモリ領域１２ａに格納されているアップデートプログラム３２Ａを利用して末端ＥＣＵ１３上のソフトウェアを更新することができる。また、図２に示したアップデート処理部１４ａはゾーンＥＣＵ１２のアップデート専用メモリ領域１２ａに格納されているアップデートプログラム３３Ａを利用してスマートアクチュエータ１４上のソフトウェアを更新することができる。

実際には、通信線１９を介してゾーンＥＣＵ１２と末端ＥＣＵ１３との間でデータ通信を行いながらアップデート処理部１３ａが末端ＥＣＵ１３上のソフトウェアを更新する。また、通信線１９を介してゾーンＥＣＵ１２とスマートアクチュエータ１４との間でデータ通信を行いながらアップデート処理部１４ａがスマートアクチュエータ１４上のソフトウェアを更新する。

なお、ゾーンＥＣＵ１２がアップデートプログラム３１Ａを利用して正常にソフトウェア更新を完了した場合には、それをゾーンＥＣＵ１２がクラウド２０に通知する。これにより、クラウド２０は不要になった車載システム１０用のアップデートプログラム３１を削除することができる。

＜ゾーンＥＣＵの動作＞
＜イグニッションオンの場合の動作＞
図３は、イグニッションオンの状態におけるゾーンＥＣＵ１２の動作を示すフローチャートである。すなわち、ゾーンＥＣＵ１２に入力されるイグニッション信号ＳＧ－ＩＧがオンの時に、図３の動作をゾーンＥＣＵ１２内のコンピュータが実行する。図３に示した動作について以下に説明する。

ゾーンＥＣＵ１２は、まだ更新インストールが完了していない必要なソフトウェア（プログラムやデータ）がアップデート専用メモリ領域１２ａ上に存在するか否かをＳ１１で確認する。そして、アップデート専用メモリ領域１２ａが空き状態の場合にＳ１２の処理に進む。

ゾーンＥＣＵ１２は、Ｓ１２で無線データ通信２５を行うことにより、クラウド２０上における必要な更新プログラム（又はデータ）の存在有無、及び更新対象などの種類を確認する。クラウド２０上に更新プログラムがある場合は、ゾーンＥＣＵ１２はＳ１３からＳ１４の処理に進む。そして、該当する更新プログラムのインストール履歴を確認する。このインストール履歴は、ゾーンＥＣＵ１２自身が管理するか、又はクラウド２０側で管理する。

ゾーンＥＣＵ１２がＳ１４でインストール履歴を確認するのは、効率的なインストール進行を可能にするためである。例えば、更新プログラムに含まれるミスなどの影響により更新に失敗したような場合は、該当する更新プログラムをインストールする優先順位を下げるか、又はその処理の再試行を後回しにすることで、同じ処理がいつまでも終了しない異常なループ状態の継続を回避できる。したがって、インストール履歴は、更新プログラム毎のインストール試行回数を管理するデータを履歴として保持している。

ゾーンＥＣＵ１２は、クラウド２０上に存在している更新プログラムの中で、インストール試行回数が最小の更新プログラムの数を確認する（Ｓ１５）。そして、インストール試行回数が最小の更新プログラムの数が１であればＳ１６の処理に進み、複数であればＳ１７の処理に進む。

ゾーンＥＣＵ１２は、次のＳ１６で、該当する１つの更新プログラムをクラウド２０から無線データ通信２５によりダウンロードしてアップデート専用メモリ領域１２ａに格納する。

ゾーンＥＣＵ１２は、次のＳ１７で、該当する複数の更新プログラムの中に、ゾーンＥＣＵ１２自身を更新対象とする更新プログラムが含まれているか否かを識別する。該当する複数の更新プログラムの中に、ゾーンＥＣＵ１２自身を更新対象とする更新プログラムが含まれている場合はＳ１８に進み、そうでない場合はＳ１９に進む。

ゾーンＥＣＵ１２は、Ｓ１８でゾーンＥＣＵ１２自身を更新対象とする１つの更新プログラムをクラウド２０から無線データ通信２５によりダウンロードしてアップデート専用メモリ領域１２ａに格納する。

ゾーンＥＣＵ１２は、Ｓ１９で末端ＥＣＵ１３、又はスマートアクチュエータ１４を更新対象とする１つ又は複数の更新プログラムをクラウド２０から無線データ通信２５によりダウンロードしてアップデート専用メモリ領域１２ａに格納する。それぞれの更新プログラムの容量が比較的小さい場合は複数の更新プログラムを同時にダウンロードしてアップデート専用メモリ領域１２ａに格納することができるが、更新プログラムの容量が大きい場合には適切な順番で１つずつダウンロードしてアップデート専用メモリ領域１２ａに格納する。

＜イグニッションオフの場合の動作＞
図４は、イグニッションオフの状態におけるゾーンＥＣＵ１２の動作を示すフローチャートである。
例えば、車両１７の運転を終了して駐車する場合には、イグニッションをオフにしてエンジンが停止して、オルタネータ１６も止まるので、車両１７上の電源電力の供給源は車載バッテリ１５だけになる。車両１７上の多くのＥＣＵはスリープなどの休止状態に移行する。そのような状況において、ゾーンＥＣＵ１２が図４の動作を実行する。図４の動作について以下に説明する。

ゾーンＥＣＵ１２は、まだ更新インストールが完了していない必要なソフトウェア（プログラムやデータ）がアップデート専用メモリ領域１２ａ上に存在するか否かをＳ２１で確認する。そして、アップデート専用メモリ領域１２ａに更新すべきソフトウェアの更新データが存在する場合にＳ２２の処理に進む。

ゾーンＥＣＵ１２は、アップデート専用メモリ領域１２ａに格納されている更新データを利用して、それが更新対象とするソフトウェアのアップデート実行を開始する。例えば、図１に示した状態であれば、アップデートプログラム３１Ａがアップデート専用メモリ領域１２ａに存在するので、アップデート処理部１２ｂがゾーンＥＣＵ１２自身のソフトウェアをアップデートプログラム３１Ａで更新するように処理する。また、図２に示したようにアップデートプログラム３２Ａがアップデート専用メモリ領域１２ａに存在する場合は、ゾーンＥＣＵ１２とアップデート処理部１３ａとの通信により、アップデート専用メモリ領域１２ａ上のアップデートプログラム３２Ａを利用して末端ＥＣＵ１３のソフトウェアを更新する。アップデートプログラム３３Ａの処理についても同様である。

ゾーンＥＣＵ１２がソフトウェアのアップデートを開始した後で、例えば車載バッテリ１５の出力電圧が異常に低下したような場合は、そのアップデートを中断してそれ以上の電源電圧低下を回避する必要がある。その場合は図４の動作を一旦終了する。その場合は、更新インストールを完了していないアップデート専用メモリ領域１２ａ上の更新データはそのまま維持する。

ゾーンＥＣＵ１２は、何の問題もなく最後までソフトウェアのアップデートを終了した場合は、該当するアップデートの成功をＳ２４で検出し、次のＳ２６の処理に進む。一方、更新データにおけるプログラムミスなどの要因により、ソフトウェアのアップデートを正しく完了できないような場合は、ゾーンＥＣＵ１２はＳ２４で該当するアップデートの失敗を検出し、それを履歴に記録して次のＳ２５に進む。その場合は、ゾーンＥＣＵ１２は該当するアップデートを開始する前のソフトウェアバージョンの状態に復元するように、Ｓ２５でロールバックを実施する。

アップデートの成功を検出した場合、又はアップデートの失敗を検出した場合には、ゾーンＥＣＵ１２は該当するアップデート用の更新データを格納しているアップデート専用メモリ領域１２ａを開放する（Ｓ２６）。つまり、更新の完了により不要になった更新データ、又は何らかの問題があって更新を完了できない不要な更新データをアップデート専用メモリ領域１２ａ上から廃棄してその分の空き領域を確保し、他の更新データの格納にアップデート専用メモリ領域１２ａを利用できるようにする。

以上のように、図１に示した車載システム１０及び図３、図４の動作を実施する車載ソフトウェア更新方法によれば、１つの更新データを格納可能なアップデート専用メモリ領域１２ａを確保するだけで、ゾーンＥＣＵ１２及びその下流に接続されている末端ＥＣＵ１３、スマートアクチュエータ１４のような複数の負荷のそれぞれのソフトウェアの更新が可能になる。つまり、１つのアップデート専用メモリ領域１２ａを有効活用することで、システム全体についてソフトウェア更新に必要とされる記憶領域を大幅に削減できる。

また、図３、図４に示したように車両１７のイグニッションのオンオフに連動して更新データのダウンロード及びアップデートを実施するので、安定した動作が期待できる。すなわち、イグニッションがオンの時には比較的長い時間に亘って省電力動作を行う必要がないので、比較的容量が大きい更新データであってもクラウド２０等から無線通信を利用して効率よくダウンロードすることができる。また、イグニッションがオフの時にはアップデート対象部位以外のＥＣＵはほぼ休止状態になるので、他のＥＣＵによる割り込み処理などの影響を受けにくくなり、安定した状況下でソフトウェアの更新処理を実行できる。

また、クラウド２０上に複数種類の更新データが同時に存在する場合には、ゾーンＥＣＵ１２を更新対象とする１つの更新データのダウンロードを優先的に実行する（Ｓ１７、Ｓ１８）ので、システム全体のソフトウェアを最新の状態でゾーンＥＣＵ１２が管理することが容易になる。

また、クラウド２０上に複数種類の更新データが同時に存在する場合には、ダウンロードの試行回数を考慮して試行回数が少ない一部の更新データを優先的に選択する（Ｓ１５、Ｓ１６）ので、システム各部のソフトウェア更新のためのダウンロードを効率よく実施できる。

ここで、上述した本発明の実施形態に係る車載ソフトウェア更新方法および車載システムの特徴をそれぞれ以下［１］～［５］に簡潔に纏めて列記する。
［１］ 最上位制御部（セントラルＥＣＵ１１）と、その下流に接続されたゾーン制御部（ゾーンＥＣＵ１２）と、その下流に接続された複数の下位制御部（末端ＥＣＵ１３、スマートアクチュエータ１４）とを有する車載システム（１０）に含まれるソフトウェアを更新するための車載ソフトウェア更新方法であって、
前記ゾーン制御部上のメモリに、前記ゾーン制御部及び前記下位制御部を更新対象とする１つの更新用データを格納可能な第１領域（アップデート専用メモリ領域１２ａ）を予め確保し、
所定のソフトウェア供給元に存在する更新用データ（アップデートプログラム３１～３３）の有無を繰り返し確認し、
第１のダウンロード条件を満たす更新用データが存在する場合に、前記更新用データを前記ソフトウェア供給元（クラウド２０）からダウンロードして前記第１領域に格納すると共に、前記第１のダウンロード条件を満たす複数の更新用データが同時に存在する場合には、前記複数の更新用データの中で優先順位の高いものを優先的に選択してダウンロードを実施する（Ｓ１５～Ｓ１８）、
車載ソフトウェア更新方法。

［２］ 最上位制御部（セントラルＥＣＵ１１）と、その下流に接続されたゾーン制御部（ゾーンＥＣＵ１２）と、その下流に接続された複数の下位制御部（末端ＥＣＵ１３、スマートアクチュエータ１４）とを有する車載システム（１０）であって、
前記ゾーン制御部上のメモリが、前記ゾーン制御部および前記複数の下位制御部のいずれか１つのソフトウェアを更新するために必要な１つの更新用データを格納可能な第１領域（アップデート専用メモリ領域１２ａ）を有し、
前記ゾーン制御部が、
前記第１領域に格納する更新用データの更新対象を選択する更新対象選択部（Ｓ１５～Ｓ１９）と、
所定のソフトウェア供給元に存在する更新用データの有無および更新対象を確認する更新制御部（Ｓ１２）と、
を備え、前記更新制御部は、第１のダウンロード条件を満たす更新用データが存在する場合に、前記更新用データを前記ソフトウェア供給元からダウンロードして前記第１領域に格納すると共に、前記第１のダウンロード条件を満たす複数の更新用データが同時に存在する場合には、前記複数の更新用データの中で優先順位の高いものを優先的に選択してダウンロードを実施する（Ｓ１６、Ｓ１８）、
車載システム。

［３］ 前記更新制御部は、自車両のイグニッション信号がオンの時に更新用データの確認およびダウンロードを実施して前記第１領域へ更新用データを格納し（Ｓ１１～Ｓ１９）、前記イグニッション信号がオフに切り替わった後で、前記第１領域に格納されている更新用データを利用して更新対象の制御部のソフトウェア更新を実行する（Ｓ２１～Ｓ２６）、
上記［２］に記載の車載システム。

［４］ 前記更新制御部は、前記ソフトウェア供給元に、前記ゾーン制御部を更新対象とする第１の更新用データ（アップデートプログラム３１）と、前記下位制御部を更新対象とする第２の更新用データ（アップデートプログラム３２、３３）とが同時に存在する場合には、前記第１の更新用データを優先的に選択する（Ｓ１７）、
上記［２］又は［３］に記載の車載システム。

［５］ 前記更新制御部は、前記ソフトウェア供給元に複数の更新用データが同時に存在する場合には、複数の中で更新処理の試行回数がより少ない更新用データを優先的に選択する（Ｓ１５）、
上記［２］乃至［４］のいずれかに記載の車載システム。

１０ 車載システム
１１ セントラルＥＣＵ
１２ ゾーンＥＣＵ
１２ａ アップデート専用メモリ領域（第１領域）
１２ｂ アップデート処理部
１３ 末端ＥＣＵ
１３ａ アップデート処理部
１４ スマートアクチュエータ
１４ａ アップデート処理部
１５ 車載バッテリ
１６ オルタネータ
１７ 車両
１８，１９ 通信線
２０ クラウド
２５ 無線データ通信
３１，３１Ａ，３２，３２Ａ，３３，３３Ａ アップデートプログラム
ＳＧ－ＩＧ イグニッション信号

Claims (5)

1. 最上位制御部と、その下流に接続されたゾーン制御部と、その下流に接続された複数の下位制御部とを有する車載システムに含まれるソフトウェアを更新するための車載ソフトウェア更新方法であって、
   前記ゾーン制御部上のメモリに、前記ゾーン制御部及び前記下位制御部を更新対象とする１つの更新用データを格納可能な第１領域を予め確保し、
   所定のソフトウェア供給元に存在する更新用データの有無を繰り返し確認し、
   第１のダウンロード条件を満たす更新用データが存在する場合に、前記更新用データを前記ソフトウェア供給元からダウンロードして前記第１領域に格納すると共に、前記第１のダウンロード条件を満たす複数の更新用データが同時に存在する場合には、前記複数の更新用データの中で優先順位の高いものを優先的に選択してダウンロードを実施する、
   車載ソフトウェア更新方法。
2. 最上位制御部と、その下流に接続されたゾーン制御部と、その下流に接続された複数の下位制御部とを有する車載システムであって、
   前記ゾーン制御部上のメモリが、前記ゾーン制御部および前記複数の下位制御部のいずれか１つのソフトウェアを更新するために必要な１つの更新用データを格納可能な第１領域を有し、
   前記ゾーン制御部が、
   前記第１領域に格納する更新用データの更新対象を選択する更新対象選択部と、
   所定のソフトウェア供給元に存在する更新用データの有無および更新対象を確認する更新制御部と、
   を備え、前記更新制御部は、第１のダウンロード条件を満たす更新用データが存在する場合に、前記更新用データを前記ソフトウェア供給元からダウンロードして前記第１領域に格納すると共に、前記第１のダウンロード条件を満たす複数の更新用データが同時に存在する場合には、前記複数の更新用データの中で優先順位の高いものを優先的に選択してダウンロードを実施する、
   車載システム。
3. 前記更新制御部は、自車両のイグニッション信号がオンの時に更新用データの確認およびダウンロードを実施して前記第１領域へ更新用データを格納し、前記イグニッション信号がオフに切り替わった後で、前記第１領域に格納されている更新用データを利用して更新対象の制御部のソフトウェア更新を実行する、
   請求項２に記載の車載システム。
4. 前記更新制御部は、前記ソフトウェア供給元に、前記ゾーン制御部を更新対象とする第１の更新用データと、前記下位制御部を更新対象とする第２の更新用データとが同時に存在する場合には、前記第１の更新用データを優先的に選択する、
   請求項２又は請求項３に記載の車載システム。
5. 前記更新制御部は、前記ソフトウェア供給元に複数の更新用データが同時に存在する場合には、複数の中で更新処理の試行回数がより少ない更新用データを優先的に選択する、
   請求項２乃至請求項４のいずれか１項に記載の車載システム。

Images