JP2023170941A - 更新制御装置、更新制御方法、及び更新制御プログラム - Google Patents

Abstract

【課題】基本ソフトウェアの更新実行後にアプリケーションソフトウェアを更新することで、アプリケーションソフトウェアが正常に動作しなくなるのを防ぐ更新制御装置及び方法を提供する。【解決手段】更新制御装置１０は、第１のソフトウェアを更新するための第１の更新ファイル及び第２のソフトウェアを更新するための第２の更新ファイルを取得するファイル取得部１０１と、第１の更新ファイルがアプリケーションソフトウェアである第１のソフトウェアを更新するための更新ファイルであり、第２の更新ファイルが基本ソフトウェアである第２のソフトウェアを更新するための更新ファイルである場合、第１のソフトウェアの更新実行後に第２のソフトウェアの更新を実行するとの更新順序を決定する更新順序決定部１０３と、決定した更新順序で第１のソフトウェアの更新及び第２のソフトウェアの更新を実行することを指示する更新指示部１０４と、を備える。【選択図】図３

Description

本発明は、主として車載の電子制御装置に搭載されたソフトウェアの更新を制御する装置である更新制御装置、更新制御装置で実現する方法、及び更新制御装置で実行可能なプログラムに関する。

自動車においては、車載ネットワークで接続された様々な電子制御装置が搭載されている。近年の自動運転技術の発展に伴い自動車に求められる機能が複雑になりつつあり、自動車に搭載される電子制御装置の数は増加しつつある。

電子制御装置の数が増加すると、電子制御装置のソフトウェアの更新が必要となった場合、それぞれの電子制御装置のソフトウェアを更新する工程も複雑になる。例えば、特許文献１には、車載装置において、ゲートウェイである車載更新装置を設け、車載更新装置が各車載ＥＣＵに更新プログラムを配信することが開示されている。

特開２０２０－１４２５６５号公報

ここで、本発明者は、詳細な検討の結果、以下の課題を見出した。
電子制御システムを構成する複数の電子制御装置の更新実行中にエラーが発生し、一部の電子制御装置の更新が完了しなかった場合、電子制御システム内には更新が完了した電子制御装置と、更新が完了していない電子制御装置とが混在することとなる。このような場合、協働する電子制御装置のバージョンが異なることによって、正常に処理が実行できないおそれがある。そのため、電子制御装置の更新が失敗した場合には、全ての電子制御装置について更新前のバージョンに戻す、いわゆるロールバック処理を行うことが望ましい。ところが、更新対象のソフトウェアの種別や、電子制御装置の構成によって、ロールバックのし易さは異なる。

そこで、本発明は、ロールバック処理が簡易なソフトウェアから更新処理を実行するように更新制御を行う装置を提供することを目的とする。

本開示の一態様による更新制御装置は、第１のソフトウェアが搭載された第１の電子制御装置、及び第２のソフトウェアが搭載された第２の電子制御装置に通信ネットワークを介して接続される更新制御装置であって、前記第１のソフトウェアを更新するための第１の更新ファイル、及び前記第２のソフトウェアを更新するための第２の更新ファイルを取得するファイル取得部（１０１）と、前記第１の更新ファイルが、アプリケーションソフトウェアである前記第１のソフトウェアを更新するための更新ファイルであり、前記第２の更新ファイルが、アプリケーションソフトウェアが動作する基礎となる基本ソフトウェアである前記第２のソフトウェアを更新するための更新ファイルである場合、前記第１のソフトウェアの更新実行後に前記第２のソフトウェアの更新を実行するとの更新順序を決定する更新順序決定部（１０３）と、前記更新順序で、前記第１の更新ファイルを用いた前記第１のソフトウェアの更新及び前記第２の更新ファイルを用いた前記第２のソフトウェアの更新を実行することを指示する更新指示部（１０４）と、を備える。

なお、特許請求の範囲、及び本項に記載した発明の構成要件に付した括弧内の番号は、本発明と後述の実施形態との対応関係を示すものであり、本発明を限定する趣旨ではない。

以上の構成によれば、ロールバック処理を考慮した順序で電子制御装置の更新処理を実行することにより、複数の電子制御装置の更新を実行している途中で、一部の電子制御装置の更新が失敗した場合であっても、ロールバック処理を容易に実行することが可能となる。

各実施形態の更新制御装置の配置を説明する図 各実施形態の電子制御システムの構成例を説明する図 各実施形態の更新制御装置の構成例を説明する図 各実施形態の更新制御装置の動作を説明する図 各実施形態の電子制御システム全体の動作を説明する図 各実施形態の電子制御システム全体の動作を説明する図 各実施形態の電子制御システム全体の動作を説明する図 各実施形態の更新順序の決定手法を用いた更新順序を説明する図 各実施形態の変形例による更新制御装置及び電子制御システムの構成例を説明する図

以下、本発明の実施形態について、図面を参照して説明する。

なお、本発明とは、特許請求の範囲又は課題を解決するための手段の項に記載された発明を意味するものであり、以下の実施形態に限定されるものではない。また、少なくともかぎ括弧内の語句は、特許請求の範囲又は課題を解決するための手段の項に記載された語句を意味し、同じく以下の実施形態に限定されるものではない。

特許請求の範囲の従属項に記載の構成及び方法は、特許請求の範囲の独立項に記載の発明において任意の構成及び方法である。従属項に記載の構成及び方法に対応する実施形態の構成及び方法、並びに特許請求の範囲に記載がなく実施形態のみに記載の構成及び方法は、本発明において任意の構成及び方法である。特許請求の範囲の記載が実施形態の記載よりも広い場合における実施形態に記載の構成及び方法も、本発明の構成及び方法の例示であるという意味で、本発明において任意の構成及び方法である。いずれの場合も、特許請求の範囲の独立項に記載することで、本発明の必須の構成及び方法となる。

実施形態に記載した効果は、本発明の例示としての実施形態の構成を有する場合の効果であり、必ずしも本発明が有する効果ではない。

複数の実施形態がある場合、各実施形態に開示の構成は各実施形態のみで閉じるものではなく、実施形態をまたいで組み合わせることが可能である。例えば一の実施形態に開示の構成を、他の実施形態に組み合わせてもよい。また、複数の実施形態それぞれに開示の構成を集めて組み合わせてもよい。

発明が解決しようとする課題に記載した課題は公知の課題ではなく、本発明者が独自に知見したものであり、本発明の構成及び方法と共に発明の進歩性を肯定する事実である。

１．各実施形態に共通の構成
（１）更新制御装置１０と電子制御システムＳの配置
図１は、各実施形態の更新制御装置１０の配置を説明する図である。例えば、図１（ａ）に示すように、更新制御装置１０が電子制御システムＳとともに「移動体」である車両に「搭載」されている場合と、図１（ｂ）に示すように、電子制御システムＳが「移動体」である車両に「搭載」され、更新制御装置１０が車両の外部に配置されたサーバ装置で実現する場合と、が想定される。

ここで、「移動体」とは、移動可能な物体をいい、移動速度は任意である。また移動体が停止している場合も当然含む。例えば、自動車、自動二輪車、自転車、歩行者、船舶、航空機、及びこれらに搭載される物を含み、またこれらに限らない。
「搭載」される、とは、移動体に直接固定されている場合の他、移動体に固定されていないが移動体と共に移動する場合も含む。例えば、移動体に乗った人が所持している場合、移動体に載置された積荷に搭載されている場合、が挙げられる。

更新制御装置１０は、電子制御システムＳを構成する複数の電子制御装置（以下、ＥＣＵ（Electronic Control Unit）と称する）に搭載されたソフトウェアの更新を制御する装置である。図２は、電子制御システムＳの構成例を示す図である。電子制御システムＳは、複数のＥＣＵ２０から構成されている。図２は３つのＥＣＵ（ＥＣＵ２０ａ～ＥＣＵ２０ｃ）を例示しているが、当然のことながら、電子制御システムＳは任意の数のＥＣＵから構成される。

図１（ａ）の場合、更新制御装置１０と各ＥＣＵ２０とは、例えばＣＡＮ（Controller Area Network）、ＬＩＮ（Local Interconnect Network）といった車載通信ネットワークを介して「接続」されている。あるいは、Ｅｔｈｅｒｎｅｔ（登録商標）やＷｉ－Ｆｉ（登録商標）、Ｂｌｕｅｔｏｏｔｈ（登録商標）等、有線無線を問わず任意の通信方式を用いて接続されてもよい。別の例として、電子制御システムＳを構成するＥＣＵ２０の少なくとも一つに、更新制御装置１０の機能を内蔵することもできる。

ここで、「接続」とは、データのやり取りが可能な状態をいい、異なるハードウェアが有線又は無線の通信ネットワークを介して接続されている場合はもちろん、同一のハードウェア上で実現された仮想マシン同士が仮想的に接続されている場合も含む。

例えば、電子制御システムＳを構成する複数のＥＣＵ２０のうち、電子制御システムＳの外部と通信を行う機能を有する外部通信ＥＣＵ２０が、更新制御装置１０の機能を内蔵する。この場合、後述する更新制御装置１０のファイル取得部１０１は、電子制御システムＳの外部（例えば、サーバ装置）から、ソフトウェアを更新するためのファイルを取得する。なお、電子制御システムＳの外部からファイルを取得するファイル取得部１０１は、ＡＵＴＯＳＡＲ（AUTomotive Open System ARchitecture）仕様においてＯＴＡ（Over The Air）クライアントと称される。

別の例では、電子制御システムＳを構成する複数のＥＣＵ２０のうち、外部通信ＥＣＵではないＥＣＵ２０が更新制御装置１０の機能を内蔵する。この場合、後述する更新制御装置１０のファイル取得部１０１は、外部通信ＥＣＵ２０を介して、電子制御システムＳの外部からファイルを取得する。なお、図１（ａ）における更新制御装置１０は、ＡＵＴＯＳＡＲ仕様においてＵＣＭ（Update and Configuration Management）マスタと称される。

図１（ｂ）の場合、更新制御装置１０と電子制御システムＳを構成する各ＥＣＵ２０とは、例えば、ＩＥＥＥ８０２．１１（Ｗｉ－Ｆｉ（登録商標））やＩＥＥＥ８０２．１６（ＷｉＭＡＸ（登録商標））、Ｗ－ＣＤＭＡ（Wideband Code Division Multiple Access）、ＨＳＰＡ（High Speed Packet Access）、ＬＴＥ（Long Term Evolution）、ＬＴＥ－Ａ（Long Term Evolution Advanced）、４Ｇ、５Ｇ等の無線通信方式といった通信ネットワークを介して「接続」されている。あるいは、ＤＳＲＣ（Dedicated Short Range Communication）を用いることができる。車両が駐車場に駐車されていたり、修理工場に収容されている場合は、無線通信方式に代えて、有線通信方式を用いることができる。例えば、ＬＡＮ（Local Area Network）やインターネット、固定電話回線を用いることができる。

図１（ｂ）の場合、サーバ装置である更新制御装置１０は、車両に搭載された電子制御システムＳを構成する各ＥＣＵ２０に搭載されたソフトウェアの更新を車両の外部から制御する。

（２）更新制御装置１０の構成
図３を用いて、更新制御装置１０の構成例を説明する。更新制御装置１０は、ファイル取得部１０１、メモリ情報取得部１０２、更新順序決定部１０３、及び更新指示部１０４を備える。

ファイル取得部１０１は、更新ファイルを取得する。図１（ａ）に示すように、更新制御装置１０が移動体に搭載されている場合、ファイル取得部１０１は、電子制御システムＳの外部に設けられたサーバ装置等からＯＴＡ（Over The Air）又は有線通信を用いて更新ファイルを取得する。図１（ｂ）に示すように、更新制御装置１０がサーバ装置で実現する場合、更新制御装置１０はサーバ装置で生成された更新ファイルを取得する。

ファイル取得部１０１が取得する更新ファイルは、各ＥＣＵ２０に搭載された「ソフトウェア」を更新するための更新ファイルを含み、例えば、複数のソフトウェアを更新するための複数の更新ファイルを含む更新ファイル群であってもよい。あるいは、ファイル取得部１０１が取得する更新ファイルは、一の更新ファイルが複数に分割されたファイルであってもよい。ファイル取得部１０１が取得するファイルはさらに、更新すべきソフトウェアを搭載しているＥＣＵを特定する情報や、それぞれの更新ファイルのデータ量を示す情報を含んでもよい。以下、更新ファイルを用いて更新すべきソフトウェアを更新対象ソフトウェアと称する。

ここで、電子制御装置に搭載される「ソフトウェア」とは、ＯＳ（Operating System）上で動作するソフトウェアはもちろん、電子制御装置そのものを動作させるミドルウェア（例えば、ＯＳ）も含む。

メモリ情報取得部１０２は、各ＥＣＵ２０が有するメモリに関するメモリ情報を取得する。メモリ情報は、例えば、各ＥＣＵ２０が有するメモリの空き容量や、メモリが有する保存領域に関する情報を示している。なお、メモリ情報取得部１０２は後述する実施形態２、３で使用される構成であり、実施形態１の更新制御装置１０は必ずしもメモリ情報取得部１０２を備えていなくともよい。

更新順序決定部１０３は、ファイル取得部１０１が取得した更新ファイルを用いて各ＥＣＵ２０に搭載されたソフトウェアの更新を実行する順序、すなわち、更新順序を決定する。更新順序決定部１０３が更新順序を決定する手法は各実施形態で詳述する。

なお、各実施形態で説明する更新順序は、一のソフトウェアの更新が「完了」した後に、次のソフトウェアの更新を実行するものとして説明する。例えば、後述する実施形態３では、保存領域の切り替えが完了したことを以って更新の完了とする。一のソフトウェアの更新が完了してから次のソフトウェアの更新を実行することで、先のソフトウェア更新が失敗した場合に、ロールバック処理を行う対象のソフトウェアを先のソフトウェアに限定することができ、次のソフトウェアについてはロールバック処理を実行せずにすむ。

ここで、更新が「完了」する、とは、例えば、更新処理が正常に終了することの他、更新処理を実行したソフトウェアが起動することであってもよい。

しかしながら、更新順序は、一のソフトウェアの更新実行後に、次のソフトウェアの更新を実行するものであればよく、一のソフトウェアの更新が完了する前に次のソフトウェアの更新処理を開始するような更新順序を決定してもよい。この場合、複数のＥＣＵ２０の更新処理が並行して実行されることがある。

更新指示部１０４は、更新順序決定部１０３が決定した更新順序で、更新ファイルを用いたソフトウェアの更新を実行することを「指示する」。図１（ａ）に示すように、更新制御装置１０が移動体に搭載されている場合、更新指示部１０４は、車載通信ネットワークを介して各ＥＣＵ２０に更新の実行を指示する。図１（ｂ）に示すように、更新制御装置１０がサーバ装置で実現する場合、更新制御装置１０は、ＯＴＡ又は有線通信を用いて、外部通信ＥＣＵ２０を介して各ＥＣＵに更新の実行を指示する。更新指示部１０４は、更新指示とともに、ファイル取得部１０１が取得した更新ファイルを送信してもよい。

ここで、更新順序で実行することを「指示する」とは、順番通りに更新を実行することが指示できればよく、その方法は問わない。例えば、更新を実行する順番を明確に指示することはもちろん、更新を実行する順番にファイルを並べ替えることによって順序を指示するものであってもよい。また、更新の「指示」は、更新を実行する電子制御装置に対して直接指示をする場合はもちろん、他の電子制御装置を介して間接的に指示する場合も含む。

例えば、更新指示部１０４は、更新順序決定部１０３が決定した更新順序で、各ＥＣＵに対して更新実行を順次指示する。具体的には、更新指示部１０４は、一のＥＣＵ２０に対して更新実行を指示し、当該ＥＣＵ２０から更新が完了したことを示す更新完了通知を受信すると、次のＥＣＵ２０に対して更新実行を指示する。あるいは、更新指示部１０４は、ＥＣＵ２０に対して一斉に更新実行を指示する。ただし、更新順序決定部１０３が決定した更新順序で各ＥＣＵ２０が更新を実行するように、更新指示部１０４は各ＥＣＵ２０が更新処理を実行する時間を指定して、更新実行を指示する。

さらに別の例では、更新指示部１０４は、ファイル取得部１０１が取得した更新ファイルを、更新順序決定部１０３が決定した更新順序に並び変える。図１（ｂ）に示すように、更新制御装置１０がサーバ装置で実現する場合、更新指示部１０４は、更新実行の指示とともに、更新順序に並んだ複数の更新ファイルを電子制御システムＳに送信する。

更新指示部１０４はさらに、各ＥＣＵ２０でのソフトウェアの更新が失敗した場合に、更新ファイルを用いた更新を実行する前の状態に戻すことを指示する。具体的には、更新指示部１０４は、一のＥＣＵ２０に対して更新実行を指示し、当該ＥＣＵ２０から更新が失敗したことを示す更新失敗通知を受信すると、当該ＥＣＵ２０よりも前にソフトウェア更新を実行したＥＣＵ２０に対して、更新を実行する前の状態に戻すことを指示する。以下、更新実行前の状態に戻す指示をロールバック指示と称する。更新指示部１０４はさらに、ソフトウェア更新が失敗したＥＣＵ２０に対してロールバック指示をしてもよい。

別の例では、更新指示部１０４は、ブロードキャストで各ＥＣＵ２０に対してロールバック指示をしてもよい。この場合、ロールバック指示を受信したＥＣＵ２０のうち、ソフトウェア更新が実行されたＥＣＵ２０のみがロールバック処理を行い、ソフトウェア更新が実行されていないＥＣＵ２０はロールバック処理を行わない。

なお、更新指示部１０４は、ロールバック指示とともに、ロールバック処理に必要なデータ、すなわち、更新前のソフトウェアのデータを送信してもよい。この場合、更新前のソフトウェアのデータは、更新制御装置１０のメモリ（図示せず）に保存されていてもよく、あるいは、ファイル取得部１０１が新たに取得してもよい。

更新指示部１０４はさらに、更新が失敗したソフトウェアの後に更新が実行される予定であったソフトウェアの「更新停止」を指示する。更新指示部１０４が、ＥＣＵ２０に対してソフトウェアの更新実行を指示していない場合は、更新停止を指示することにより、更新指示の送信を取りやめる。あるいは、更新指示部１０４が、ＥＣＵ２０に対して既に更新実行の指示をしている場合は、更新実行を取り消す指示を送信することで、更新停止を指示する。

ここで、「更新停止」の指示とは、既に送信した更新指示を取り消す場合の他、更新指示の送信を取りやめることも含む。

（３）電子制御システムＳ及びＥＣＵ２０
図２を用いて電子制御システムＳを説明する。図２に示すとおり、電子制御システムＳは複数のＥＣＵ２０から構成される。各ＥＣＵ２０は、ソフトウェアの更新を実行する更新部２０１及びメモリ２０２を有する。図２及び以下の説明では、各ＥＣＵ２０及び各ＥＣＵ２０が有する構成を区別するために、それぞれの符号にａ～ｃを付している。

更新部２０１は、更新指示部１０４からの指示に基づき、更新ファイルを用いたソフトウェアの更新処理を行う。更新部２０１は、ＡＵＴＯＳＡＲ仕様においてＵＣＭサブオーディネイトとも称される。

更新部２０１は、ソフトウェアの更新処理が完了すると、更新制御装置１０に更新が完了したこと示す更新完了通知を送信する。また、ソフトウェアの更新処理が失敗すると、更新制御装置１０に更新が失敗したこと示す更新失敗通知を送信する。

更新部２０１はさらに、更新指示部１０４からロールバック指示を受信した場合、ソフトウェアを更新前の状態に戻すためのロールバック処理を行う。ロールバック処理を行うためには、更新前のソフトウェアのデータが必要となる。メモリ２０２が更新前のソフトウェアのデータを保存している場合には、更新部２０１はメモリ２０２に保存されているデータを用いてロールバック処理を行う。また、メモリ２０２が更新前のソフトウェアのデータを保存していない場合には、更新指示部１０４から更新前のソフトウェアのデータを取得する。

メモリ２０２は、ＲＯＭ、フラッシュメモリ、又はハードディスク等の不揮発性メモリであり、各ＥＣＵに搭載されたソフトウェア及び更新ファイルを保存する。図２には図示していないが、メモリ２０２は複数の保存領域を有していてもよい。

本実施形態の各ＥＣＵ２０は例えば、ＡＵＴＯＳＡＲ仕様においてAdaptive Platform（以下、ＡＰ）と呼ばれる、動的な機能の拡張が可能なプラットフォームをベースとしたＥＣＵである。ＡＰは主に、自動運転用のＥＣＵに適したプラットフォームである。あるいは、これらのＥＣＵは例えば、ＡＵＴＯＳＡＲ仕様においてClassic Platform（以下、ＣＰ）と呼ばれる、静的な機能を最適化したプラットフォームをベースとしたＥＣＵであってもよい。なお、ＣＰは主に、車両制御用のＥＣＵに適したプラットフォームである。

（４）電子制御システムＳ及び更新制御装置１０の動作
図４を用いて本実施形態の更新制御装置１０の動作を、図５を用いて電子制御システムＳ全体の動作を、それぞれ説明する。なお、図４に示す動作は、更新制御装置１０で実行される更新制御方法を示すだけでなく、更新制御装置１０で実行可能な更新制御プログラムの処理手順を示すものである。そして、これらの処理は、図４で示した順序には限定されない。すなわち、あるステップでその前段のステップの結果を利用する関係にある等の制約がない限り、順序を入れ替えてもよい。図５、及び後述する図６、図７についても同様である。

更新制御装置１０のファイル取得部１０１は、各ＥＣＵ２０に搭載されたソフトウェアを更新するための更新ファイルを取得する（Ｓ１０１）。図４、図５の例では、更新制御装置１０は、ＥＣＵ２０ａに搭載されたソフトウェアａを更新するための更新ファイルａ、ＥＣＵ２０ｂに搭載されたソフトウェアｂを更新するための更新ファイルｂ、及びＥＣＵ２０ｃに搭載されたソフトウェアｃを更新するための更新ファイルｃを取得するものとする。

更新順序決定部１０３は、Ｓ１０１で取得した更新ファイルを用いたソフトウェアの更新を実行する更新順序を決定する（Ｓ１０２）。図５では、ソフトウェアａ、ソフトウェアｂ、ソフトウェアｃの順序で更新を実行するとの更新順序を決定するものとする。

更新指示部１０４は、Ｓ１０２で決定した更新順序でソフトウェアの更新を実行することを指示する（Ｓ１０３）。ここで、図５の例では、更新が完了したＥＣＵから更新完了通知を受信した場合に、次のＥＣＵに対して更新実行の指示をするものとする。したがって、更新指示部１０４は、まずＥＣＵ２０ａに対して更新実行を指示する。

更新制御装置１０から更新実行指示を受信したＥＣＵ２０ａの更新部２０１ａは、更新処理を実行する（Ｓ２０１）。そして、更新処理が完了すると、更新制御装置１０に対して更新完了通知を送信する。

更新制御装置１０は、ＥＣＵ２０ａから更新完了通知を受信（Ｓ１０４、Ｓ１０５：Ｎ）すると、次に更新すべきソフトウェアｂを搭載するＥＣＵ２０ｂに対して更新実行を指示する（Ｓ１０３）。

更新制御装置１０から更新実行指示を受信したＥＣＵ２０ｂの更新部２０１ｂは、更新処理を実行する（Ｓ２０１）。ここで、更新部２０１ｂによる更新処理が失敗すると、ＥＣＵ２０ｂは更新制御装置１０に対して更新失敗通知を送信する。

更新制御装置１０は、ＥＣＵ２０ｂから更新失敗通知を受信（Ｓ１０４、Ｓ１０５：Ｙ）すると、更新が失敗したＥＣＵ２０ｂ、及び、既に更新が完了しているＥＣＵ２０ａに対して、ロールバック指示を送信する（Ｓ１０６）。

更新制御装置１０からロールバック指示を受信したＥＣＵ２０ａ、２０ｂの更新部２０１ａ、２０１ｂはロールバック処理を実行する（Ｓ２０２）。なお、図５の例では、更新制御装置１０はＥＣＵ２０ｃに対して更新実行を指示していないため、ＥＣＵ２０ｃに対してロールバック指示を送信する必要はない。そして、ＥＣＵ２０ｃに対する更新指示の送信を取りやめる。これにより、ＥＣＵ２０ａ、ＥＣＵ２０ｂ、ＥＣＵ２０ｃのいずれも、更新処理を実行する前の状態となる。

図６、図７は、図５とは異なる電子制御システムＳの動作を説明する図である。図５とは異なり、図６では、更新制御装置１０は、ＥＣＵ２０ａ、ＥＣＵ２０ｂ、ＥＣＵ２０ｃに対して一斉に更新実行を指示する（Ｓ１０３）。ただし、更新順序決定部１０３が決定した順序でＥＣＵ２０ａ、ＥＣＵ２０ｂ、ＥＣＵ２０ｃが更新処理を実行するように、例えば、更新処理を実行する時間を指定して更新実行を指示する。

図６に示す更新制御装置１０では、ＥＣＵ２０ｂから更新失敗通知を受信（Ｓ１０４）すると、更新実行を指示した全てのＥＣＵ２０ａ～２０ｃに対してロールバック指示を送信する（Ｓ１０６）。すなわち、図５ではロールバック指示を送信していないＥＣＵ２０ｃに対してもロールバック指示を送信する。ただし、ＥＣＵ２０ｃでは更新処理が実行されていないため、ＥＣＵ２０ｃではロールバック指示を受信してもロールバック処理は実行されない。

図７は、更新が失敗したＥＣＵ２０ｂは、更新制御装置１０からロールバック指示を受けることなく、自律的にロールバック処理を行う例を示している。図５、図６と同様、更新制御装置１０から更新実行の指示を受信したＥＣＵ２０ｂは更新処理を行い（Ｓ２０１）、更新処理が失敗すると、更新失敗通知を更新制御装置１０に送信する。そして、ＥＣＵ２０ｂは、ロールバック処理を行う（Ｓ２０２）。すなわち、図７では、更新処理が失敗したＥＣＵ２０よりも前に更新処理が完了したＥＣＵ２０ａに対してのみ、ロールバック指示を送信する。

２．第１の実施形態
（１）更新順序の決定手法
本実施形態は、ＥＣＵ２０に搭載された更新対象ソフトウェアの更新種別に応じて、更新順序を決定するものである。すなわち、更新種別が、イメージ更新（image update）であるか、アプリケーション更新（application update）であるか、に応じて、更新順序を決定する。

イメージ更新とは、メモリ２０２のパーティション単位でソフトウェアを書き換える更新をいう。パーティション（partition）は、面（bank）あるいは保存領域とも呼ばれる。パーティションとしては、論理的なパーティション（logical partition）の他、物理的なメモリを単位したパーティションが挙げられる。イメージ更新は、更新後のパーティションのイメージデータをパーティションに書込むことで実施できる。このイメージデータが、ファイル取得部１０１が車両外から取得するイメージ更新のための更新ファイルの一例である。ファイル取得部１０１が車両外から取得するイメージ更新のための更新ファイルは、更新後のパーティションのソフトウェアとの差分を示すファイルであってもよい。この場合、差分を示すファイルと、更新対象ＥＣＵのパーティションに格納されているソフトウェアと、から、車両内において、書込みに用いるイメージデータを生成する。イメージ更新は、典型的には、ＯＳやＡＵＴＯＳＡＲプラットフォーム（以下、ＰＦ）そのものを更新する際に使用される。一のパーティションに記憶されているソフトウェアが、ＯＳやＡＵＴＯＳＡＲ ＰＦに加えて、ＯＳやＡＵＴＯＳＡＲ ＰＦ上で動作するアプリケーションを含む場合、イメージ更新においてＯＳやＡＵＴＯＳＡＲ ＰＦと共に、ＯＳやＡＵＴＯＳＡＲ ＰＦ上で動作するアプリケーションの更新も一緒に行うことが出来る。以上であるから、イメージ更新は、「基本ソフトウェア」の更新とも称することができる。

ここで、「基本ソフトウェア」には、ＯＳはもちろん、電子制御装置に仮想マシンを構成するソフトウェアや、電子制御装置にプラットフォームを構成するソフトウェアが挙げられる。

アプリケーション更新は、メモリ２０２のパーティションに格納されているソフトウェアをアプリケーション単位で書き込む、あるいは書き換える更新を言う。ここで言うアプリケーションとしては、ＯＳやＡＵＴＯＳＡＲ ＡＰ上で動作するアプリケーションの他、ＡＵＴＯＳＡＲ ＡＰのＦｕｎｃｔｉｏｎａｌ Ｃｌｕｓｔｅｒと呼ばれるプラットフォームを構成するソフトウェア部品、アプリケーションが利用するパラメタ等などのデータセットが挙げられる。なお、アプリケーションの一例としてはＰＯＳＩＸＯＳ等のＯＳ上で動作する実行形式ファイルが挙げられる。アプリケーション更新は、アプリケーションソフトウェアの更新とも称することができる。

例えば、ファイル取得部１０１が、図２に示すＥＣＵのうち、ＥＣＵ２０ａ（「第１の電子制御装置」に相当）に搭載されたソフトウェアａ（「第１のソフトウェア」に相当）を更新するための更新ファイルａと、ＥＣＵ２０ｂ（「第２の電子制御装置」に相当）に搭載されたソフトウェアｂ（「第２のソフトウェア」に相当）を更新するための更新ファイルｂとを取得した場合を例に挙げて説明する。

本実施形態の更新順序決定部１０３は、ファイル取得部１０１が取得した更新ファイルａ、更新ファイルｂがそれぞれ、アプリケーションソフトウェア又は基本ソフトウェアのいずれを更新するためのソフトウェアであるかを判定する。更新ファイルａ（「第１の更新ファイル」に相当）がアプリケーションソフトウェアを更新するための更新ファイルであり、更新ファイルｂ（「第２の更新ファイル」に相当）が基本ソフトウェアを更新するための更新ファイルである場合、更新順序決定部１０３は、ソフトウェアａの更新実行後に、ソフトウェアｂの更新を実行するとの更新順序を決定する。すなわち、アプリケーションソフトウェアの更新実行後に、基本ソフトウェアの更新を実行することを決定する。なお、ここでは、アプリケーションソフトウェアの更新と、基本ソフトウェアの更新と、が、別のＥＣＵに対する更新であることを想定しているが、一のＥＣＵの別パーティションに対する更新であってもよい。アプリケーションソフトウェアの更新と、基本ソフトウェアの更新と、が、一のＥＣＵの別パーティションに対する更新としてなされるのは、例えば、一のＥＣＵが、ＯＳやＰＦを格納するパーティションを、そのＯＳやＰＦ上で動作するアプリケーションを格納するパーティションとは別に有している場合である。

基本ソフトウェアは、アプリケーションソフトウェアが動作する基礎となるソフトウェアであるため、基本ソフトウェアの更新を実行している間、基本ソフトウェア上で動作するアプリケーションソフトウェアの機能、あるいはＥＣＵ２０自体の機能が停止するおそれがある。基本ソフトウェアのロールバック処理を実行している間も、同様のことが起こりうる。つまり、基本ソフトウェアのロールバック処理は、複数のアプリケーションソフトウェアの機能停止を伴うおそれがある。また、基本ソフトウェアをロールバックする処理は、ＥＣＵの再起動を伴う場合が多い。これに対し、アプリケーションソフトウェアでは、更新処理及びロールバック処理を実行している間、同じＥＣＵ２０に搭載された他のアプリケーションソフトウェアを動作させることができる。アプリケーションソフトウェアをロールバックする処理は、基本ソフトウェアをロールバックする処理と比べて、ＥＣＵの起動状態を継続したまま実施できる場合が多い。アプリケーションソフトウェアのロールバックは、基本ソフトウェアをロールバックよりも容易であると言える。また、基本ソフトウェアのロールバック処理よりも、アプリケーションソフトウェアのロールバック処理の方が、他のアプリケーションソフトウェアに与える影響は少ない場合が多い。

そこで、本実施形態では、アプリケーションソフトウェアの更新実行後に、基本ソフトウェアの更新を実行するとの更新順序を決定する。すなわち、ロールバック容易なものから順に更新を実行するとの更新順序とを決定する。これにより、ＥＣＵ２０の更新が失敗し、ロールバック処理が必要となった場合であっても、基本ソフトウェアのロールバック処理が行われる可能性を低減することができる。

（２）変形例
上述した実施形態では、ＥＣＵの同じパーティションに保存されたソフトウェアの更新が、アプリケーションソフトウェア又は基本ソフトウェアのいずれか一方であることを前提として、更新順序を決定する例を説明した。しかしながら、一のＥＣＵ２０の同じパーティションに保存された基本ソフトウェア及びアプリケーションソフトウェアの双方について更新が必要となることがある。

例えば、ＥＣＵ２０ａのアプリケーションソフトウェアであるソフトウェアａ１、ＥＣＵ２０ａの基本ソフトウェアであるソフトウェアａ２、及びＥＣＵ２０ｂのアプリケーションソフトウェアであるソフトウェアｂの更新を実行する場合、上述した実施形態１によれば、更新順序決定部１０３は、ＥＣＵ２０ａのソフトウェアａ１及びＥＣＵ２０ｂのソフトウェアｂの更新実行後に、ＥＣＵ２０ａのソフトウェアａ２の更新を実行するとの更新順序を決定する。

ところが、アプリケーションソフトウェアでは、当該ソフトウェアが動作する基礎となる基本ソフトウェアのバージョンが指定されていることがある。このような場合、基本ソフトウェアの更新前にアプリケーションソフトウェアの更新を実行すると、アプリケーションソフトウェアのバージョンと基本ソフトウェアのバージョンとが異なることとなり、アプリケーションソフトウェアは正常に動作しないことが起こりうる。

そこで、一のＥＣＵにおいて、基本ソフトウェア及びアプリケーションソフトウェアの双方の更新が必要な場合には、基本ソフトウェアの更新を実行してからアプリケーションソフトウェアの更新を実行してもよい。

例えば、ＥＣＵ２０ａのアプリケーションソフトウェアであるソフトウェアａ１、ＥＣＵ２０ａの基本ソフトウェアであるソフトウェアａ２、及びＥＣＵ２０ｂのアプリケーションソフトウェアであるソフトウェアｂの更新を実行する場合、本変形例の更新順序決定部１０３は、ＥＣＵ２０ｂのソフトウェアｂの更新実行後に、ＥＣＵ２０ａのソフトウェアａ２の更新を実行し、その後にＥＣＵ２０ａのソフトウェアａ１の更新を実行するとの更新順序を決定する。

以上のとおり、本変形によれば、一のＥＣＵにおいて基本ソフトウェア及びアプリケーションソフトウェアの双方の更新を行う場合には、基本ソフトウェアの更新実行後にアプリケーションソフトウェアの更新を実行する。これにより、アプリケーションソフトウェアと基本ソフトウェアのバージョンが異なることで、アプリケーションソフトウェアが正常に動作しなくなるのを防ぐことができる。

３．第２の実施形態
本実施形態は、更新ファイルのデータ量及びＥＣＵのメモリの空き容量に応じて、更新順序を決定するものである。なお、メモリの空き容量とは、更新対象ソフトウェアを保存しているメモリ、すなわち、更新ファイルの書き込み先であるメモリのパーティションの空き容量と同義である。

本実施形態では、メモリ情報取得部１０２は、各ＥＣＵ２０が有するメモリの空き容量を示すメモリ情報を取得する。

更新順序決定部１０３は、ファイル取得部１０１が取得したそれぞれの更新ファイルのデータ量、及び、メモリ情報取得部１０２が取得した各ＥＣＵ２０のメモリの空き容量に基づき、更新順序を決定する。具体的には、データ量が空き容量よりも小さい更新ファイルを用いたソフトウェアの更新実行後に、データ量が空き容量よりも大きい更新ファイルを用いたソフトウェアの更新を実行するとの更新順序を決定する。

例えば、ファイル取得部１０１が、図２に示す複数のＥＣＵ２０のうち、ＥＣＵ２０ａ（「第１の電子制御装置」に相当）に搭載されたソフトウェアａ（「第１のソフトウェア」に相当）を更新するための更新ファイルａ（「第１の更新ファイル」に相当）と、ＥＣＵ２０ｃ（「第３の電子制御装置」に相当）に搭載されたソフトウェアｃ（「第３のソフトウェア」に相当）を更新するための更新ファイルｃ（「第３の更新ファイル」に相当）とを取得した場合を例に挙げて説明する。ここで、更新ファイルａ、更新ファイルｃはいずれも、アプリケーションソフトウェアを更新するための更新ファイルであるものとする。

メモリ情報取得部１０２は、ＥＣＵ２０ａのメモリ２０２ａ（「第１のメモリ」に相当）の空き容量（「第１の空き容量」に相当）、及びＥＣＵ２０ｃのメモリ２０２ｃ（「第２のメモリ」に相当）の空き容量（「第２の空き容量」に相当）を示すメモリ情報をそれぞれ取得する。

そして、更新順序決定部１０３は、更新ファイルａのデータ量（「第１のデータ量」に相当）がメモリ２０２ａの空き容量よりも大きいか否か、及び、更新ファイルｃのデータ量（「第２のデータ量」に相当）がメモリ２０２ｃの空き容量よりも大きいか否か、を判定する。ここで、更新ファイルａのデータ量がメモリ２０２ａの空き容量よりも小さく、更新ファイルｃのデータ量がメモリ２０２ｃの空き容量よりも大きいと判定した場合、更新順序決定部１０３は、ソフトウェアａの更新実行後に、ソフトウェアｃの更新を実行するとの更新順序を決定する。すなわち、本実施形態では、メモリの空き容量よりも小さいデータ量の更新ファイルを先に実行することを決定する。

更新ファイルのデータ量がメモリの空き容量よりも大きい場合、更新前のソフトウェアを削除又は上書きして更新ファイルを書き込むことで、更新処理を実行する。そのため、仮に更新部２０１での更新が失敗してロールバック処理を実行する場合、更新前のソフトウェアのデータを再度取得しなければ、ロールバック処理をすることができない。これに対し、更新ファイルのデータ量がメモリの空き容量がよりも小さい場合、更新部２０１は、メモリ２０２の空き容量に更新ファイルを書き込み、元のソフトウェアをメモリ２０２に残しておくことができる。すなわち、更新部２０１は、メモリ２０２に、更新前のソフトウェア及び更新後のソフトウェアを保存する。そして、更新処理が完了すると、実行するソフトウェアを、更新前のソフトウェアから更新後のソフトウェアに切り替える。また、更新部２０１での更新が失敗した場合であっても、メモリ２０２に残された更新前のソフトウェアを使用することで、容易にロールバック処理を行うことが可能となる。

なお、上述したとおり、基本ソフトウェアの更新、すなわち、イメージ更新はパーティション単位で書き込み又は書き換えを実施するため、１つのパーティション全体が、更新前及び更新後の何れかとなる。したがって、上述した構成は、イメージ更新とアプリケーション更新とのうち、パーティションに格納されているソフトウェアをアプリケーション単位で書き込み又は書き換えるアプリケーション更新にのみ適用することができる。

次に、更新順序決定部１０３は、更新ファイルａ、更新ファイルｃのデータ量がいずれも、メモリ２０２ａ、メモリ２０２ｃそれぞれの空き容量よりも小さい場合、又は大きい場合を説明する。この場合、更新順序決定部１０３は、更新ファイルのデータ量が小さいものから順に更新を実行するとの更新順序を決定する。例えば、更新ファイルａのデータ量が１０ＭＢであり、更新ファイルｃのデータ量が２０ＭＢの場合、更新ファイルａを用いたソフトウェアａの更新実行後に、更新ファイルｃを用いたソフトウェアｃの更新を実行するとの更新順序を決定する。

更新ファイルのデータ量が小さいほど、ロールバック処理に要する時間及び処理負荷は少ない。そこで、データ量が小さい更新ファイルを用いたソフトウェアの更新を先に実行することで、ロールバック処理が必要となった場合であっても、処理負荷が大きいソフトウェアのロールバック処理が行われる可能性を低減することができる。

４．第３の実施形態
（１）更新順序の決定手法
本実施形態は、各ＥＣＵ２０が有するメモリ２０２の保存領域の数に応じて、更新順序を決定するものである。

本実施形態では、メモリ情報取得部１０２は、各ＥＣＵ２０が有するメモリの保存領域の数を示すメモリ情報を取得する。

更新順序決定部１０３は、メモリ情報取得部１０２が取得した、各ＥＣＵ２０が有するメモリ２０２の「保存領域の数」に基づき、更新順序を決定する。具体的には、複数の保存領域を有するメモリ２０２を有するＥＣＵ２０に搭載されたソフトウェアの更新実行後に、１つの保存領域を有するメモリ２０２を有するＥＣＵ２０に搭載されたソフトウェアの更新を実行するとの更新順序を決定する。上述したとおり、メモリ２０２の保存領域とは、メモリ２０２のパーティション又は面とも称される。

ここで、「保存領域の数」とは、メモリ内にデータを格納できる領域の数である。「保存領域の数」が複数とは、物理的に２つのメモリが存在することによって保存領域が複数となる場合はもちろん、物理的に１つのメモリにおいて、複数のアドレスを用いて保存領域を区切ることで、保存領域を複数とする場合も含む。

メモリ２０２が複数の保存領域を有する場合、複数の保存領域のうち１つの領域が、ＥＣＵ２０が運用する保存領域となり、他の保存領域は運用しない保存領域となる。すなわち、メモリ２０２が複数の保存領域を有するとは、運用保存領域と非運用保存領域とを有することを意味する。なお、ＥＣＵ２０の運用保存領域と非運用保存領域とは適宜切り替えることが可能である。例えば、ＥＣＵ２０が２つの保存領域（保存領域Ａ、Ｂ）を有する場合、保存領域Ａを運用保存領域として使用している間、保存領域Ｂは非運用保存領域となる。保存領域Ａが運用保存領域である間、ＥＣＵ２０は保存領域Ａに保存されているソフトウェアを使用することができ、保存領域Ｂに保存されているソフトウェアは使用することはできない。そして、運用保存領域を保存領域Ａから保存領域Ｂに切り替えることで、使用するソフトウェアも切り替えることができる。

以下に、ファイル取得部１０１が、図２に示す複数のＥＣＵ２０のうち、ＥＣＵ２０ａに搭載されたソフトウェアａを更新するための更新ファイルａと、ＥＣＵ２０ｃに搭載されたソフトウェアｃを更新するための更新ファイルｃとを取得した場合を例に挙げて説明する。ここで、更新ファイルａ、更新ファイルｃはいずれも、基本ソフトウェアを更新するための更新ファイルであるものとする。

メモリ情報取得部１０２は、ＥＣＵ２０ａのメモリ２０２ａ（「第１のメモリ」に相当）の保存領域の数と、ＥＣＵ２０ｃのメモリ２０２ｃ（「第２のメモリ」に相当）の保存領域の数とを示すメモリ情報をそれぞれ取得する。

そして、更新順序決定部１０３は、メモリ２０２ａの保存領域の数、及びメモリ２０２ｃの保存領域の数をそれぞれ判定する。ここで、メモリ２０２ａが複数の保存領域を有し、メモリ２０２ｃが１つの保存領域を有する場合、更新順序決定部１０３は、ソフトウェアａの更新実行後に、ソフトウェアｃの更新を実行するとの更新順序を決定する。すなわち、本実施形態では、複数の保存領域を有するメモリを搭載するＥＣＵのソフトウェアの更新を先に実行することを決定する。

メモリ２０２が複数の保存領域を有している場合、一の保存領域に更新前のソフトウェアを残したまま、別の保存領域に更新後のソフトウェアを保存することができる。例えば、更新部２０１は、メモリ２０２の運用保存領域に更新前のソフトウェアを残したまま、非運用保存領域に更新後のソフトウェアを保存する。そして、更新処理が完了した後、運用する保存領域を切り替えることにより、ＥＣＵ２０は更新後のソフトウェアを実行することが可能となる。なお、更新前のソフトウェアは、全てのＥＣＵ２０における更新が完了後に削除してもよい。

メモリ２０２が複数の保存領域を有している場合、更新部２０１によるソフトウェア更新が失敗した場合であっても、他方の保存領域に残された更新前のソフトウェアの使用を継続することができる。

なお、本実施形態は、基本ソフトウェアの更新を例示して説明したが、本実施形態はアプリケーションソフトウェアにも適用することが可能である。すなわち、一の保存領域に更新前のアプリケーションソフトウェアを残したまま、別の保存領域に更新後のソフトウェアを保存することができる。

ただし、アプリケーションソフトウェアについては、更新後のアプリケーションソフトウェアのバージョンと、ＯＳやプラットフォームのバージョンとが異なる場合、更新後のアプリケーションソフトウェアが正常に動作しないことがある。この場合、更新後のアプリケーションソフトウェアを保存する保存領域は、当該アプリケーションソフトウェアと同じバージョンの基本ソフトウェアが保存された保存領域に限定される。

例えば、更新後のアプリケーションソフトウェアのバージョンが、運用保存領域に保存されたＯＳのバージョンと同じであって、非運用保存領域に保存されたＯＳのバージョンとは異なる場合、更新後のアプリケーションソフトウェアは運用保存領域に保存しなければ正常に動作しない可能性がある。この場合、アプリケーションソフトウェアは運用保存領域に保存される。なお、更新制御装置１０は、各保存領域のバージョンを考慮して、いずれの保存領域にアプリケーションソフトウェアを保存するかを指示してもよい。

５．実施形態１～３の組み合わせ
更新順序決定部１０３は、上述した実施形態１～３の更新順序の決定手法を組み合わせて、各ＥＣＵ２０に搭載されたソフトウェアの更新順序を決定してもよい。以下に、実施形態１乃至３を組み合わせた場合の更新順序の決定を説明する。ただし、上述した実施形態１～３のうち２つの実施形態の更新順序の決定手法を組み合わせてもよい。

図８は、更新対象ソフトウェアが、アプリケーションソフトウェア又は基本ソフトウェアのいずれであるか、更新ファイルのデータ量がメモリの空き容量よりも大きいか否か、及び、メモリの保存領域が１又は複数のいずれであるかに基づき、更新順序決定部１０３が決定した順序を示している。

更新順序決定部１０３は、以下の更新順序で更新処理を実行することを決定する。
・メモリ２０２が複数の保存領域を有しているＥＣＵ２０のアプリケーションソフトウェアであって、且つ、更新ファイルのデータ量がメモリ２０２の空き容量よりも小さいソフトウェアの更新
・メモリ２０２が１つの保存領域を有しているＥＣＵ２０のアプリケーションソフトウェアであって、且つ、更新ファイルのデータ量がメモリ２０２の空き容量よりも小さいソフトウェアの更新
・メモリ２０２が複数の保存領域を有しているＥＣＵ２０のアプリケーションソフトウェアであって、且つ、更新ファイルのデータ量がメモリ２０２の空き容量よりも大きいソフトウェアの更新
・メモリ２０２が１つの保存領域を有しているＥＣＵ２０のアプリケーションソフトウェアであって、且つ、更新ファイルのデータ量がメモリ２０２の空き容量よりも大きいソフトウェアの更新
・メモリ２０２が複数の保存領域を有しているＥＣＵ２０の基本ソフトウェアの更新
・メモリ２０２が１つの保存領域を有しているＥＣＵ２０の基本ソフトウェアの更新

実施形態１において説明したように、基本ソフトウェアのロールバック処理は、アプリケーションソフトウェアの機能停止を伴うおそれがある。そのため、アプリケーションソフトウェアの更新実行後に基本ソフトウェアの更新を実行する。

さらに、実施形態２において説明したように、更新ファイルのデータ量がメモリ２０２の空き容量よりも小さい場合、更新前のアプリケーションソフトウェアのデータを保存領域に残しておくことができるため、更新前のアプリケーションソフトウェアのデータを新たに取得せずに、ロールバック処理を実行することができる。そのため、メモリの空き容量よりも小さいデータ量の更新ファイルを用いたソフトウェアの更新実行後に、メモリの空き容量よりも大きいデータ量の更新ファイルを用いたソフトウェアの更新を実行する。

さらに、実施形態３において説明したように、メモリ２０２が複数の保存領域を有する場合、更新前のソフトウェアのデータを非運用保存領域に残しておくことができるため、更新前のソフトウェアのデータを新たに取得せずに、ロールバック処理を実行することができる。そのため、複数の保存領域を有するメモリ２０２を搭載したＥＣＵ２０のソフトウェアの更新実行後に、１つの保存領域を有するメモリ２０２を搭載したＥＣＵ２０のソフトウェアの更新を実行する。

なお、ＥＣＵ２０に搭載されたソフトウェアのうち、一部のソフトウェアでは複数の保存領域を使用し、一部のソフトウェアでは一つの保存領域を使用することがある。例えば、ＯＳでは１つの保存領域のみを使用し、アプリケーションでは複数の保存領域を使用することがある。このような場合、複数の保存領域を有しているＥＣＵ２０のアプリケーションソフトウェアの更新を実行し、その後、１つの保存領域を有しているＥＣＵ２０の基本ソフトウェアの更新を実行することとなる。

６．各実施形態の変形例
上述した実施形態では、電子制御システムＳを構成する各ＥＣＵ２０がそれぞれ異なるハードウェアであることを前提として説明した。また、図１（ａ）に示すように、更新制御装置１０が移動体に搭載されている場合には、更新制御装置１０と各ＥＣＵ２０とが異なるハードウェアであることを前提として説明した。しかしながら、図１（ａ）における更新制御装置１０及び各ＥＣＵ２０は、それぞれ異なるハードウェアである構成に限定されるものではない。

図９を用いて、本変形例の電子制御システムＳの一例を説明する。図９は、電子制御システムＳを構成するＥＣＵとして、２つのＥＣＵ１００ａ、１００ｂを図示しているが、当然のことながら電子制御システムＳは任意の数のＥＣＵから構成される。電子制御システムＳを構成するＥＣＵは、それぞれ仮想マシン（図面上は、ＶＭ（Virtual Machine）と略する。）を有する。

ＥＣＵ１００ａは、仮想マシン１０、２０ａ、ハイパーバイザ（図面上は、ＨＶ（Hypervisor）と略する。）１１０、及び実ストレージ１２０を備える。ハイパーバイザ１１０は、ＥＣＵ１００ａを仮想化するソフトウェアである。図９の例では、仮想マシン１０、２０ａはハイパーバイザ１１０上に構築されている。ハイパーバイザ１１０上に構築された仮想マシン同士はそれぞれ仮想的に接続されている。

ＥＣＵ１００ｂは、ＥＣＵ１００ａと通信ネットワークを介して接続されたＥＣＵであり、仮想マシン２０ｂ、ハイパーバイザ２１０、及び実ストレージ２２０を備える。ＥＣＵ１００ａと同様、ハイパーバイザ２１０はＥＣＵ１００ｂを仮想化するソフトウェアであり、仮想マシン２０ｂはハイパーバイザ２１０上に構築されている。

実ストレージ１２０、２２０はいずれもハードウェアのメモリであり、ＳＲＡＭやＤＲＡＭといった揮発性メモリ、ＲＯＭ、フラッシュメモリ、又はハードディスク等の不揮発性メモリである。各仮想マシン２０ａの保存部２０２ａは実ストレージ１２０の保存領域を仮想化して実現される仮想メモリである。保存部２０２ｂも同様である。

本変形例の仮想マシン１０は、ファイル取得部１０１、メモリ情報取得部１０２、更新順序決定部１０３、及び更新指示部１０４を実現する。本変形例のファイル取得部１０１、メモリ情報取得部１０２、更新順序決定部１０３、及び更新指示部１０４の機能及び動作は各実施形態と同じである。すなわち、本変形例の仮想マシン１０は、上述した実施形態１～３の更新制御装置１０として機能する。

また、本実施形態の仮想マシン２０ａ、２０ｂはそれぞれ、各実施形態のＥＣＵ２０ａ、ＥＣＵ２０ｂと同様、更新部（２０１ａ、２０１ｂ）、及びメモリ（２０２ａ、２０２ｂ）を実現する。本変形例の更新部２０１ａ、２０１ｂ、及びメモリ２０２ａ、２０２ｂの機能及び動作は各実施形態と同じである。すなわち、本変形例の仮想マシン２０ａ、２０ｂは、上述した実施形態１～３のＥＣＵ２０ａ～２０ｃとして機能する。

７．総括
以上、本発明の各実施形態における更新制御装置の特徴について説明した。

各実施形態で使用した用語は例示であるので、同義の用語、あるいは同義の機能を含む用語に置き換えてもよい。

実施形態の説明に用いたブロック図は、装置の構成を機能毎に分類及び整理したものである。それぞれの機能を示すブロックは、ハードウェア又はソフトウェアの任意の組み合わせで実現される。また、機能を示したものであることから、かかるブロック図は方法の発明、及び当該方法を実現するプログラムの発明の開示としても把握できるものである。

各実施形態に記載した処理、フロー、及び方法として把握できる機能ブロック、については、一のステップでその前段の他のステップの結果を利用する関係にある等の制約がない限り、順序を入れ替えてもよい。

各実施形態、及び特許請求の範囲で使用する、第１、第２、乃至、第Ｎ（Ｎは整数）、の用語は、同種の２以上の構成や方法を区別するために使用しており、順序や優劣を限定するものではない。

各実施形態の更新制御装置は、車両に搭載される車載システムを構成する電子制御装置の更新を制御するための装置であることを前提としているが、本発明の更新制御装置は、特許請求の範囲で特に限定する場合を除き、任意の電子制御装置の更新を制御する装置に適用される。

また、本発明の装置の形態の例として、以下のものが挙げられる。
部品の形態として、半導体素子、電子回路、モジュール、マイクロコンピュータが挙げられる。
半完成品の形態として、電子制御装置（ＥＣＵ（Electric Control Unit））、システムボードが挙げられる。
完成品の形態として、携帯電話、スマートフォン、タブレット、パーソナルコンピュータ（ＰＣ）、ワークステーション、サーバが挙げられる。
その他、通信機能を有するデバイス等を含み、例えばビデオカメラ、スチルカメラ、カーナビゲーションシステムが挙げられる。

また各装置に、アンテナや通信用インターフェースなど、必要な機能を追加してもよい。

加えて、本発明は、各実施形態で説明した構成及び機能を有する専用のハードウェアで実現できるだけでなく、メモリやハードディスク等の記録媒体に記録した本発明を実現するためのプログラム、及びこれを実行可能な専用又は汎用ＣＰＵ及びメモリ等を有する汎用のハードウェアとの組み合わせとしても実現できる。

専用や汎用のハードウェアの非遷移的実体的記録媒体（例えば、外部記憶装置（ハードディスク、ＵＳＢメモリ、ＣＤ／ＢＤ等）、又は内部記憶装置（ＲＡＭ、ＲＯＭ等））に格納されるプログラムは、記録媒体を介して、あるいは記録媒体を介さずにサーバから通信回線を経由して、専用又は汎用のハードウェアに提供することもできる。これにより、プログラムのアップグレードを通じて常に最新の機能を提供することができる。

本開示は、主として自動車に搭載される車載用電子制御装置用の更新制御装置として説明したが、自動二輪車、船舶、鉄道、航空機等、移動する移動体全般に適用することが可能である。また、移動体に限らず、マイクロコンピュータを包含する製品全般に適用可能である。

１０ 更新制御装置、１０１ ファイル取得部、１０２ メモリ情報取得部、１０３ 更新順序決定部、１０４ 更新指示部

Claims (13)

1. 第１のソフトウェアが搭載された第１の電子制御装置、及び第２のソフトウェアが搭載された第２の電子制御装置に通信ネットワークを介して接続される更新制御装置であって、
   前記第１のソフトウェアを更新するための第１の更新ファイル、及び前記第２のソフトウェアを更新するための第２の更新ファイルを取得するファイル取得部（１０１）と、
   前記第１の更新ファイルが、アプリケーションソフトウェアである前記第１のソフトウェアを更新するための更新ファイルであり、前記第２の更新ファイルが、アプリケーションソフトウェアが動作する基礎となる基本ソフトウェアである前記第２のソフトウェアを更新するための更新ファイルである場合、前記第１のソフトウェアの更新実行後に前記第２のソフトウェアの更新を実行するとの更新順序を決定する更新順序決定部（１０３）と、
   前記更新順序で、前記第１の更新ファイルを用いた前記第１のソフトウェアの更新及び前記第２の更新ファイルを用いた前記第２のソフトウェアの更新を実行することを指示する更新指示部（１０４）と、
   を備える、更新制御装置（１０）。
2. 前記更新順序決定部は、前記第１のソフトウェアの更新が完了した後に、前記第２のソフトウェアの更新を実行するとの前記更新順序を決定する、
   請求項１記載の更新制御装置。
3. 当該更新制御装置はさらに、
   第３のソフトウェアが搭載された第３の電子制御装置に前記通信ネットワークを介して接続され、
   前記第１の電子制御装置が有する第１のメモリの空き容量である第１の空き容量、及び前記第３の電子制御装置が有する第２のメモリの空き容量である第２の空き容量を示すメモリ情報を取得するメモリ情報取得部（１０２）を備えており、
   前記ファイル取得部はさらに、アプリケーションソフトウェアである前記第３のソフトウェアを更新するための第３の更新ファイルを取得し、
   前記更新順序決定部は、前記第１の更新ファイルのデータ量である第１のデータ量、前記第３の更新ファイルのデータ量である第２のデータ量、前記第１の空き容量、及び前記第２の空き容量に基づき、前記第１のソフトウェア及び前記第３のソフトウェアの更新順序を決定する、
   請求項１記載の更新制御装置。
4. 前記第１のデータ量が前記第１の空き容量よりも小さく、前記第２のデータ量が前記第２の空き容量よりも大きい場合、前記更新順序決定部は、前記第１のソフトウェアの更新実行後に前記第３のソフトウェアの更新を実行するとの前記更新順序を決定する、
   請求項３記載の更新制御装置。
5. 前記第１のデータ量が前記第１の空き容量よりも小さく、前記第２のデータ量が前記第２の空き容量よりも小さく且つ前記第１のデータ量よりも大きい場合、前記更新順序決定部は、前記第１のソフトウェアの更新実行後に前記第３のソフトウェアの更新を実行するとの前記更新順序を決定する、
   請求項３記載の更新制御装置。
6. 前記更新順序決定部はさらに、前記第１のメモリが有する保存領域の数及び前記第２のメモリが有する保存領域の数に基づき、前記更新順序を決定する、
   請求項３記載の更新制御装置。
7. 前記第１のメモリが複数の保存領域を有し、前記第２のメモリが１つの保存領域を有する場合、前記更新順序決定部は、前記第１のソフトウェアの更新実行後に前記第３のソフトウェアの更新を実行するとの前記更新順序を決定する、
   請求項６記載の更新制御装置。
8. 前記更新指示部は、前記第２の更新ファイルを用いた前記第２のソフトウェアの更新が失敗した場合に、前記第１のソフトウェアを、前記第１の更新ファイルを用いた更新を実行する前の状態に戻すことを指示する、
   請求項１記載の更新制御装置。
9. 前記更新指示部は、前記第１の更新ファイルを用いた前記第１のソフトウェアの更新が失敗した場合に、前記第２の更新ファイルを用いた前記第２のソフトウェアの更新停止を指示する、
   請求項１記載の更新制御装置。
10. 当該更新制御装置は、前記第１の電子制御装置及び前記第２の電子制御装置とともに移動体に搭載されている、
    請求項１～９のいずれかに記載の更新制御装置。
11. 前記第１の電子制御装置及び前記第２の電子制御装置は移動体に搭載されており、
    当該更新制御装置は、前記移動体の外部に配置されている、
    請求項１～９のいずれかに記載の更新制御装置。
12. 第１のソフトウェアが搭載された第１の電子制御装置、及び第２のソフトウェアが搭載された第２の電子制御装置に通信ネットワークを介して接続される更新制御装置で実行される更新制御方法であって、
    前記第１のソフトウェアを更新するための第１の更新ファイル、及び前記第２のソフトウェアを更新するための第２の更新ファイルを取得し、
    前記第１の更新ファイルが、アプリケーションソフトウェアである前記第１のソフトウェアを更新するための更新ファイルであり、前記第２の更新ファイルが、アプリケーションソフトウェアが動作する基礎となる基本ソフトウェアである前記第２のソフトウェアを更新するための更新ファイルである場合、前記第１のソフトウェアの更新実行後に前記第２のソフトウェアの更新を実行するとの更新順序を決定し、
    前記更新順序で、前記第１の更新ファイルを用いた前記第１のソフトウェアの更新及び前記第２の更新ファイルを用いた前記第２のソフトウェアの更新を実行することを指示する、
    更新制御方法。
13. 第１のソフトウェアが搭載された第１の電子制御装置、及び第２のソフトウェアが搭載された第２の電子制御装置に通信ネットワークを介して接続される更新制御装置で実行可能な更新制御プログラムであって、
    前記第１のソフトウェアを更新するための第１の更新ファイル、及び前記第２のソフトウェアを更新するための第２の更新ファイルを取得し、
    前記第１の更新ファイルが、アプリケーションソフトウェアである前記第１のソフトウェアを更新するための更新ファイルであり、前記第２の更新ファイルが、アプリケーションソフトウェアが動作する基礎となる基本ソフトウェアである前記第２のソフトウェアを更新するための更新ファイルである場合、前記第１のソフトウェアの更新実行後に前記第２のソフトウェアの更新を実行するとの更新順序を決定し、
    前記更新順序で、前記第１の更新ファイルを用いた前記第１のソフトウェアの更新及び前記第２の更新ファイルを用いた前記第２のソフトウェアの更新を実行することを指示する、
    更新制御プログラム。