ホーム > 特許ランキング > 日立Ａｓｔｅｍｏ株式会社
知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024008514
(43)【公開日】2024-01-19
(54)【発明の名称】車両制御装置
(51)【国際特許分類】
G06F 8/65 20180101AFI20240112BHJP
G06F 9/50 20060101ALI20240112BHJP
B60R 16/02 20060101ALI20240112BHJP
【ＦＩ】
G06F8/65
G06F9/50 150A
B60R16/02 660U
【審査請求】未請求
【請求項の数】6
【出願形態】ＯＬ
(21)【出願番号】P 2022110451
(22)【出願日】2022-07-08
(71)【出願人】
【識別番号】509186579
【氏名又は名称】日立Ａｓｔｅｍｏ株式会社
(74)【代理人】
【識別番号】110000925
【氏名又は名称】弁理士法人信友国際特許事務所
(72)【発明者】
【氏名】福田 毅
(72)【発明者】
【氏名】溝口 将史
(72)【発明者】
【氏名】前田 功治
(72)【発明者】
【氏名】蛯名 朋仁
(72)【発明者】
【氏名】村上 隆
【テーマコード（参考）】
5B376
【Ｆターム（参考）】
5B376CA01
5B376CA41
5B376CA43
5B376GA07
(57)【要約】
【課題】ハードウェアリソースが枯渇する場合であっても、ソフトウェアアップデートを可能にする。
【解決手段】車両制御装置は、第一の演算部と第二の演算部とを備える。ここで、第一の演算部の実行状況と新たに実装される新ソフトウェアの構成に基づき、第一の演算部において既存ソフトウェアを新ソフトウェアにアップデート可能かを判断すると共に、新ソフトウェアの全構成を第一の演算部においてアップデート可能か、あるいは新ソフトウェアの一部構成を第二の演算部に配置変更するかを、リソース情報保持部の保持情報から判断する。そして、第二の演算部へ配置変更すると判断した場合に、新ソフトウェアの実行時に伴う第一の演算部と第二の演算部との間でのレイテンシを考慮して、第二の演算部へ配置する新ソフトウェア構成の一部を決定する。
【選択図】図１
【解決手段】車両制御装置は、第一の演算部と第二の演算部とを備える。ここで、第一の演算部の実行状況と新たに実装される新ソフトウェアの構成に基づき、第一の演算部において既存ソフトウェアを新ソフトウェアにアップデート可能かを判断すると共に、新ソフトウェアの全構成を第一の演算部においてアップデート可能か、あるいは新ソフトウェアの一部構成を第二の演算部に配置変更するかを、リソース情報保持部の保持情報から判断する。そして、第二の演算部へ配置変更すると判断した場合に、新ソフトウェアの実行時に伴う第一の演算部と第二の演算部との間でのレイテンシを考慮して、第二の演算部へ配置する新ソフトウェア構成の一部を決定する。
【選択図】図１
【特許請求の範囲】
【請求項1】
既存ソフトウェアを実行する第一の演算部と、前記既存ソフトウェアとは別のソフトウェアを実行する第二の演算部とを備えて、車両の制御を行う車両制御装置であり、
前記第一の演算部の実行状況と新たに実装される新ソフトウェアの構成に基づき、前記第一の演算部において前記既存ソフトウェアを前記新ソフトウェアにアップデート可能か判断するアップデート判断部と、
前記アップデート判断部の判断結果に応じて、前記既存ソフトウェアのアップデートを実行するアップデート実行部と、
前記車両の動作中に使用されるリソース情報を監視するリソース監視部と、
前記リソース監視部から提供されるリソース使用状況に基づきリソース使用量情報を保持するリソース情報保持部と、
前記第一の演算部が実行している前記既存ソフトウェアあるいは新ソフトウェアの構成の一部の配置変更を、前記第二の演算部に依頼するソフトウェア配置変更依頼送受信部と、を備え、
前記アップデート判断部は、前記新ソフトウェアの全構成を前記第一の演算部においてアップデート可能か、あるいは前記新ソフトウェアの一部構成を前記第二の演算部に配置変更するかを、前記リソース情報保持部の保持情報から判断し、
前記アップデート判断部が前記第二の演算部へ前記配置変更すると判断した場合に、前記ソフトウェア配置変更依頼送受信部が前記第二の演算部に依頼し、
前記ソフトウェア配置変更依頼送受信部は、前記新ソフトウェアの構成の一部の配置変更を行う際に、前記新ソフトウェアの実行時に伴う前記第一の演算部と前記第二の演算部とのレイテンシを考慮して、前記第二の演算部へ配置する前記新ソフトウェア又は前記既存ソフトウェアの構成の一部を決定する
車両制御装置。
前記第一の演算部の実行状況と新たに実装される新ソフトウェアの構成に基づき、前記第一の演算部において前記既存ソフトウェアを前記新ソフトウェアにアップデート可能か判断するアップデート判断部と、
前記アップデート判断部の判断結果に応じて、前記既存ソフトウェアのアップデートを実行するアップデート実行部と、
前記車両の動作中に使用されるリソース情報を監視するリソース監視部と、
前記リソース監視部から提供されるリソース使用状況に基づきリソース使用量情報を保持するリソース情報保持部と、
前記第一の演算部が実行している前記既存ソフトウェアあるいは新ソフトウェアの構成の一部の配置変更を、前記第二の演算部に依頼するソフトウェア配置変更依頼送受信部と、を備え、
前記アップデート判断部は、前記新ソフトウェアの全構成を前記第一の演算部においてアップデート可能か、あるいは前記新ソフトウェアの一部構成を前記第二の演算部に配置変更するかを、前記リソース情報保持部の保持情報から判断し、
前記アップデート判断部が前記第二の演算部へ前記配置変更すると判断した場合に、前記ソフトウェア配置変更依頼送受信部が前記第二の演算部に依頼し、
前記ソフトウェア配置変更依頼送受信部は、前記新ソフトウェアの構成の一部の配置変更を行う際に、前記新ソフトウェアの実行時に伴う前記第一の演算部と前記第二の演算部とのレイテンシを考慮して、前記第二の演算部へ配置する前記新ソフトウェア又は前記既存ソフトウェアの構成の一部を決定する
車両制御装置。
【請求項2】
前記アップデート判断部は、前記新ソフトウェアの全構成を前記第一の演算部においてアップデート可能か、あるいは前記新ソフトウェアの一部構成を前記第二の演算部に配置変更するかを、前記リソース情報保持部の保持情報の一部である中央処理ユニットの負荷率、メモリ使用量、レイテンシの少なくともいずれか１つに基づいて判断する
請求項１に記載の車両制御装置。
請求項１に記載の車両制御装置。
【請求項3】
前記アップデート判断部は、前記車両の任意のタイミングで、前記新ソフトウェアの全構成を前記第一の演算部においてアップデート可能か、あるいは前記新ソフトウェアの一部構成を前記第二の演算部に配置変更するかを、前記リソース情報保持部の保持情報の一部である中央処理ユニットの負荷率、メモリ使用量、レイテンシの少なくともいずれか１つに基づいて判断する
請求項１に記載の車両制御装置。
請求項１に記載の車両制御装置。
【請求項4】
前記任意のタイミングは、前記車両の停車時、前記車両の駐車時、前記車両の充電時、前記車両のユーザインターフェースによる通知時のいずれかのタイミングである
請求項３に記載の車両制御装置。
請求項３に記載の車両制御装置。
【請求項5】
前記アップデート判断部が前記第二の演算部へ配置変更すると判断する際に、ハードウェアリソースの使用量が最適になるように、前記既存ソフトウェアの中から前記第二の演算部へ配置変更するソフトウェアを選択する
請求項１に記載の車両制御装置。
請求項１に記載の車両制御装置。
【請求項6】
前記ハードウェアリソースは、中央処理ユニットの負荷率、メモリ使用量、レイテンシの少なくともいずれか１つである
請求項５に記載の車両制御装置。
請求項５に記載の車両制御装置。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、車両制御装置に関する。
【背景技術】
【0002】
車両制御装置(ＥＣＵ：Electronic Control Unit)に搭載されたソフトウェアを、製品リリース後にアップデートする技術がある。車両電子制御の高度化は年々進んでおり、製品リリース後にソフトウェアをアップデートすることで、常に最新の制御ソフトウェアを車両に搭載する価値は大きい。ただし、車両制御装置はプロセッサ性能やメモリ量などのハードウェアリソース量が限定される場合が多いため、限られたハードウェアリソースを有効に活用したソフトウェアアップデート手法が有効とされている。
【0003】
例えば特許文献１には、ソフトウェアの更新情報により更新するモジュールを依存させる順に並べて記憶部の空き容量を計算し、空き容量が不足しないようにモジュールの更新順序を変更してソフトウェアを更新する技術が記載されている。これにより、例えモジュールを記憶する空き容量が、更新するソフトウェアの容量よりも小さい場合であっても、ソフトウェアを更新することを可能としている。
【先行技術文献】
【特許文献】
【0004】
【特許文献1】特開２００７－２１３１８９号公報
【発明の概要】
【発明が解決しようとする課題】
【0005】
特許文献１に記載された技術によれば、モジュールの更新順序を変化させることで、モジュールを記憶する記憶部の空き容量が小さい場合であっても、ソフトウェアが更新可能となる。しかしながら、１つのシステムの記憶容量を超えてのソフトウェアアップデートは不可能なため、例えば１０年単位で利用されるような製品寿命が長いシステムにおいては、活用できる空き容量の限界を迎えてしまい、ハードウェアリソース枯渇によってソフトウェアアップデートができなくなるという問題があった。
【0006】
本発明は、ハードウェアリソースが枯渇する場合であっても、ソフトウェアアップデートを可能とする車両制御装置を提供することを目的とする。
【課題を解決するための手段】
【0007】
上記課題を解決するために、例えば特許請求の範囲に記載の構成を採用する。
本願は、上記課題を解決する手段を複数含んでいるが、その一例を挙げるならば、
既存ソフトウェアを実行する第一の演算部と、既存ソフトウェアとは別のソフトウェアを実行する第二の演算部とを備えて、車両の制御を行う車両制御装置に適用したものである。
そして、車両制御装置は、
第一の演算部の実行状況と新たに実装される新ソフトウェアの構成に基づき、第一の演算部において既存ソフトウェアを新ソフトウェアにアップデート可能か判断するアップデート判断部と、
アップデート判断部の判断結果に応じて、既存ソフトウェアのアップデートを実行するアップデート実行部と、
車両の動作中に使用されるリソース情報を監視するリソース監視部と、
リソース監視部から提供されるリソース使用状況に基づきリソース使用量情報を保持するリソース情報保持部と、
第一の演算部が実行している既存ソフトウェアあるいは新ソフトウェアの構成の一部の配置変更を、第二の演算部に依頼するソフトウェア配置変更依頼送受信部と、を備える。
さらに、アップデート判断部は、新ソフトウェアの全構成を第一の演算部においてアップデート可能か、あるいは新ソフトウェアの一部構成を第二の演算部に配置変更するかを、リソース情報保持部の保持情報から判断し、
アップデート判断部が第二の演算部へ配置変更すると判断した場合に、ソフトウェア配置変更依頼送受信部が第二の演算部に依頼し、
ソフトウェア配置変更依頼送受信部は、新ソフトウェア構成の一部の配置変更を行う際に、新ソフトウェアの実行時に伴う第一の演算部と第二の演算部との間でのレイテンシを考慮して、第二の演算部へ配置する新ソフトウェア構成の一部を決定する。
本願は、上記課題を解決する手段を複数含んでいるが、その一例を挙げるならば、
既存ソフトウェアを実行する第一の演算部と、既存ソフトウェアとは別のソフトウェアを実行する第二の演算部とを備えて、車両の制御を行う車両制御装置に適用したものである。
そして、車両制御装置は、
第一の演算部の実行状況と新たに実装される新ソフトウェアの構成に基づき、第一の演算部において既存ソフトウェアを新ソフトウェアにアップデート可能か判断するアップデート判断部と、
アップデート判断部の判断結果に応じて、既存ソフトウェアのアップデートを実行するアップデート実行部と、
車両の動作中に使用されるリソース情報を監視するリソース監視部と、
リソース監視部から提供されるリソース使用状況に基づきリソース使用量情報を保持するリソース情報保持部と、
第一の演算部が実行している既存ソフトウェアあるいは新ソフトウェアの構成の一部の配置変更を、第二の演算部に依頼するソフトウェア配置変更依頼送受信部と、を備える。
さらに、アップデート判断部は、新ソフトウェアの全構成を第一の演算部においてアップデート可能か、あるいは新ソフトウェアの一部構成を第二の演算部に配置変更するかを、リソース情報保持部の保持情報から判断し、
アップデート判断部が第二の演算部へ配置変更すると判断した場合に、ソフトウェア配置変更依頼送受信部が第二の演算部に依頼し、
ソフトウェア配置変更依頼送受信部は、新ソフトウェア構成の一部の配置変更を行う際に、新ソフトウェアの実行時に伴う第一の演算部と第二の演算部との間でのレイテンシを考慮して、第二の演算部へ配置する新ソフトウェア構成の一部を決定する。
【発明の効果】
【0008】
本発明によれば、車両の制御を実現するソフトウェアの処理時のレイテンシを考慮しつつ、複数の演算部の間でソフトウェア配置を変更することで、ハードウェアリソースが枯渇する場合であっても、ソフトウェアのアップデートが実現できるようになる。
上記した以外の課題、構成及び効果は、以下の実施形態の説明により明らかにされる。
上記した以外の課題、構成及び効果は、以下の実施形態の説明により明らかにされる。
【図面の簡単な説明】
【0009】
【図1】本発明の一実施の形態例による車両制御装置の全体構成を示すブロック図である。
【図2】本発明の一実施の形態例による車両制御装置の車両の内部の配置例を示す構成図である。
【図3】本発明の一実施の形態例にて演算処理される既存ソフトウェアの一例を示す図である。
【図4】本発明の一実施の形態例の第一の演算部の処理手順を示すフローチャートである。
【図5】本発明の一実施の形態例のリソース使用量の一例を示す図である。
【図6】本発明の一実施の形態例の最悪リソース使用量の一例を示す図である。
【図7】本発明の一実施の形態例のリソース監視部の処理手順を示すフローチャートである。
【図8】本発明の一実施の形態例による新ソフトウェアのリソース使用量の一例を示す図である。
【図9】本発明の一実施の形態例のアップデート判断部の処理手順を示すフローチャートである。
【図10】本発明の一実施の形態例による判断結果の一例を示す図である。
【図11】本発明の一実施の形態例のアップデート実行部の処理手順を示すフローチャートである。
【図12】本発明の一実施の形態例による配置変更依頼情報１０９の一例を示す図である。
【図13】本発明の一実施の形態例のソフトウェア配置変更依頼送受信部の処理手順を示すフローチャートである。
【図14】本発明の一実施の形態例によるソフトウェアアップデート前のソフトウェア配置例を示す図である。
【図15】本発明の一実施の形態例によるソフトウェアアップデート後のソフトウェア配置例を示す図である。
【発明を実施するための形態】
【0010】
以下、本発明の一実施の形態例（以下、「本例」と称する）を、添付図面を参照して説明する。
【0011】
［車両制御装置の構成］
図１は、本例の車両制御装置１のソフトウェア更新のための機能の全体構成を示すブロック図である。
本例の車両制御装置１は、車両に搭載されて走行などを制御する装置であり、図２で説明するように、１台の車両に複数設置されて、複数の車両制御装置１がネットワークで接続されている。それぞれの車両制御装置１は、実装されたソフトウェアを演算部によって実行することで、車両の制御動作を行うコンピュータとして構成される。
車両制御装置１は、図１に示すように、既存ソフトウェア保持部１０１に、動作を行うためのソフトウェア（既存ソフトウェア）が保持されている。この既存ソフトウェアは、外部から供給される新ソフトウェアによりアップデートを行うことができる。ここでの新ソフトウェアは、既存ソフトウェアの少なくとも一部をアップデートするために用いられるものである。なお、図面ではソフトウェアを「ＳＷ」と略記している。
図１は、本例の車両制御装置１のソフトウェア更新のための機能の全体構成を示すブロック図である。
本例の車両制御装置１は、車両に搭載されて走行などを制御する装置であり、図２で説明するように、１台の車両に複数設置されて、複数の車両制御装置１がネットワークで接続されている。それぞれの車両制御装置１は、実装されたソフトウェアを演算部によって実行することで、車両の制御動作を行うコンピュータとして構成される。
車両制御装置１は、図１に示すように、既存ソフトウェア保持部１０１に、動作を行うためのソフトウェア（既存ソフトウェア）が保持されている。この既存ソフトウェアは、外部から供給される新ソフトウェアによりアップデートを行うことができる。ここでの新ソフトウェアは、既存ソフトウェアの少なくとも一部をアップデートするために用いられるものである。なお、図面ではソフトウェアを「ＳＷ」と略記している。
【0012】
車両制御装置１が既存ソフトウェアを新ソフトウェアにアップデートする際には、新ソフトウェアのリソース使用量情報２が、車両制御装置１に供給される。この新ソフトウェアリソース使用量情報２は、新ソフトウェアと共に外部から取得されるが、車両内で新ソフトウェアを受信した際に生成するようにしてもよい。
【0013】
図１に示す車両制御装置１の構成は、車両制御装置１が既存ソフトウェアを新ソフトウェアにアップデートする際に必要な構成になっている。この図１に示す各部の構成は、車両制御装置１を作動させるソフトウェアにより構成され、同様に図１に示す各情報は、同じソフトウェアにより取得される。なお、図１に示される各構成の処理の詳細は図３以降で説明する。
【0014】
まず、図１に示す車両制御装置１の全体構成について説明する。車両制御装置１は、既存ソフトウェア保持部１０１、第一の演算部１０２、リソース使用量情報１０３、リソース監視部１０４、リソース情報保持部１０５、および最悪リソース使用量情報１０６を備える。
また、車両制御装置１は、アップデート判断部１０７、アップデート判断結果情報１０８、配置変更依頼情報１０９、アップデート実行部１１０、およびソフトウェア配置変更依頼送受信部１１１を備える。なお、リソース使用量情報１０３、アップデート判断結果情報１０８、および配置変更依頼情報１０９は、それぞれ対応した保持部に保持される。
また、車両制御装置１は、アップデート判断部１０７、アップデート判断結果情報１０８、配置変更依頼情報１０９、アップデート実行部１１０、およびソフトウェア配置変更依頼送受信部１１１を備える。なお、リソース使用量情報１０３、アップデート判断結果情報１０８、および配置変更依頼情報１０９は、それぞれ対応した保持部に保持される。
【0015】
また、図１に示す車両制御装置１の外部には、第二の演算部３が用意される。この第二の演算部３は、車両内に複数設けられた別の車両制御装置に用意されるものである。車両に複数の車両制御装置が用意される構成については図２で後述する。
【0016】
既存ソフトウェア保持部１０１は、車両制御装置１が実行するソフトウェアを保持する。既存ソフトウェア保持部１０１が保持した既存ソフトウェアは、第一の演算部１０２で実行される。
第一の演算部１０２で実行中のリソース使用量は、車両制御装置１内で計測され、計測したリソース使用量情報１０３が保持される。
リソース使用量情報１０３は、リソース監視部１０４に送られて、リソース監視部１０４で監視される。
リソース監視部１０４における監視結果は、リソース情報保持部１０５に保持される。リソース情報保持部１０５は、保持する情報の一つとして最悪リソース使用量情報１０６を有する。
第一の演算部１０２で実行中のリソース使用量は、車両制御装置１内で計測され、計測したリソース使用量情報１０３が保持される。
リソース使用量情報１０３は、リソース監視部１０４に送られて、リソース監視部１０４で監視される。
リソース監視部１０４における監視結果は、リソース情報保持部１０５に保持される。リソース情報保持部１０５は、保持する情報の一つとして最悪リソース使用量情報１０６を有する。
【0017】
アップデート判断部１０７は、新ソフトウェアのリソース使用量情報２と、リソース情報保持部１０５に保持された最悪リソース使用量情報１０６とに基づいて、第一の演算部１０２におけるソフトウェアの実行が可能か否かを判定して、新ソフトウェアへのアップデートの可否を判断する。そして、アップデート判断部１０７は、新ソフトウェアへのアップデートの可否の判断に基づいて、アップデート判断結果情報１０８を生成する。
アップデート実行部１１０は、アップデート判断結果情報１０８に基づいて既存ソフトウェア保持部１０１が保持した既存ソフトウェアを、新ソフトウェアにアップデートさせる。
アップデート実行部１１０は、アップデート判断結果情報１０８に基づいて既存ソフトウェア保持部１０１が保持した既存ソフトウェアを、新ソフトウェアにアップデートさせる。
【0018】
また、アップデート判断部１０７は、第一の演算部１０２で新ソフトウェアへのアップデートができないと判定したとき、配置変更依頼情報１０９を生成する。アップデート判断部１０７が生成した配置変更依頼情報１０９は、ソフトウェア配置変更依頼送受信部１１１から、別の車両制御装置が備える第二の演算部３に送信される。
【0019】
配置変更依頼情報１０９を受信した第二の演算部３は、配置変更依頼情報１０９に基づいて、実行するソフトウェアを変更する。ここでのソフトウェアの変更には、新ソフトウェアを実行する場合の他、既存ソフトウェア保持部１０１で保持された既存ソフトウェアの少なくとも一部を実行する場合も含まれる。
なお、第二の演算部３を備える車両制御装置も、図１に示す車両制御装置１と同様の構成を備えており、配置変更が指示されたソフトウェアが実行可能か否かを判断して、実行可能であるときに、配置変更依頼に基づいた配置変更を行う。
なお、第二の演算部３を備える車両制御装置も、図１に示す車両制御装置１と同様の構成を備えており、配置変更が指示されたソフトウェアが実行可能か否かを判断して、実行可能であるときに、配置変更依頼に基づいた配置変更を行う。
【0020】
［複数の車両制御装置の配置構成］
図２は、車両Ｍに複数の車両制御装置が配置される例を示す。ここでは、第一車両制御装置１ａ、第二車両制御装置１ｂ、第三車両制御装置１ｃ、および第四車両制御装置１ｄの４つの車両制御装置が配置される例を示している。各車両制御装置１ａ～１ｄは、ネットワークＮＷで接続され、相互にデータの送受信が可能になっている。また、ネットワークＮＷに接続される各車両制御装置１ａ～１ｄは、車両の外部などとデータのやり取りを行うための送受信部または通信ポートを備えており、外部から新ソフトウェアなどの情報を取得することができる。
各車両制御装置１ａ～１ｄは、演算部（図１における演算部１０２に相当）を備えると共に、その演算部で実行するソフトウェアをアップデートするために、図１に示す構成を備える。
図２は、車両Ｍに複数の車両制御装置が配置される例を示す。ここでは、第一車両制御装置１ａ、第二車両制御装置１ｂ、第三車両制御装置１ｃ、および第四車両制御装置１ｄの４つの車両制御装置が配置される例を示している。各車両制御装置１ａ～１ｄは、ネットワークＮＷで接続され、相互にデータの送受信が可能になっている。また、ネットワークＮＷに接続される各車両制御装置１ａ～１ｄは、車両の外部などとデータのやり取りを行うための送受信部または通信ポートを備えており、外部から新ソフトウェアなどの情報を取得することができる。
各車両制御装置１ａ～１ｄは、演算部（図１における演算部１０２に相当）を備えると共に、その演算部で実行するソフトウェアをアップデートするために、図１に示す構成を備える。
【0021】
ここで、各車両制御装置１ａ～１ｄのハードウェア構成を説明すると、例えば第一車両制御装置１ａは、ＣＰＵ（中央処理ユニット）１１とワークメモリ１２と記憶部１３とインターフェース（Ｉ／Ｆ）１４とを備え、これらが相互にデータ転送可能に接続されている。
ＣＰＵ１１は、記憶部１３に記憶されたプログラム（ソフトウェア）をワークメモリ１２内で実行する。これにより、ワークメモリ１２内に図１に示す各処理部が構成される。
記憶部１３は、車両制御を行うプログラムを記憶すると共に、画像や制御データなどを記憶する。記憶部１３に記憶されるプログラムには、ソフトウェアのアップデート処理を行うためのプログラムも含まれる。
ＣＰＵ１１は、記憶部１３に記憶されたプログラム（ソフトウェア）をワークメモリ１２内で実行する。これにより、ワークメモリ１２内に図１に示す各処理部が構成される。
記憶部１３は、車両制御を行うプログラムを記憶すると共に、画像や制御データなどを記憶する。記憶部１３に記憶されるプログラムには、ソフトウェアのアップデート処理を行うためのプログラムも含まれる。
【0022】
インターフェース１４は、カメラや各種センサの検出データの入力処理や、車両の制御データの出力処理を行う。
第一車両制御装置１ａ以外の車両制御装置１ｂ～１ｄも、第一車両制御装置１ａと同様の構成を有する。
なお、以下の説明で車両制御装置１と述べた場合、これら複数の車両制御装置１ａ～１ｄのいずれか一つを示すものとする。
第一車両制御装置１ａ以外の車両制御装置１ｂ～１ｄも、第一車両制御装置１ａと同様の構成を有する。
なお、以下の説明で車両制御装置１と述べた場合、これら複数の車両制御装置１ａ～１ｄのいずれか一つを示すものとする。
【0023】
［車両制御装置にて演算処理されるソフトウェアの例］
図３は、車両制御装置１にて演算処理される既存ソフトウェアの１０１の処理と周期情報に関するデータＤ１１の一例を示す図である。
ここでは、車両制御装置１で演算処理される既存ソフトウェア１０１による処理の例として、センサフュージョン、オブジェクトトラッキング、ローカルマップ作成、軌道生成、制御値算出が示されている。
それぞれのソフトウェアによる処理は、演算処理される周期を示すタスクを有する。例えば、図３のデータＤ１１の例では、センサフュージョン、オブジェクトトラッキング、およびローカルマップ作成は、40ms周期で演算処理される。また、軌道生成と制御値算出は、10ms周期で演算処理される。
図３は、車両制御装置１にて演算処理される既存ソフトウェアの１０１の処理と周期情報に関するデータＤ１１の一例を示す図である。
ここでは、車両制御装置１で演算処理される既存ソフトウェア１０１による処理の例として、センサフュージョン、オブジェクトトラッキング、ローカルマップ作成、軌道生成、制御値算出が示されている。
それぞれのソフトウェアによる処理は、演算処理される周期を示すタスクを有する。例えば、図３のデータＤ１１の例では、センサフュージョン、オブジェクトトラッキング、およびローカルマップ作成は、40ms周期で演算処理される。また、軌道生成と制御値算出は、10ms周期で演算処理される。
【0024】
［演算部での演算処理］
図４は、第一の演算部１０２における処理手順を示したフローチャートである。
まず、第一の演算部１０２は、既存ソフトウェア１０１を取得する（ステップＳ１１）。そして、第一の演算部１０２は、取得したソフトウェアを演算処理して、ソフトウェアに基づいた制御などを実行する（ステップＳ１２）。
図４は、第一の演算部１０２における処理手順を示したフローチャートである。
まず、第一の演算部１０２は、既存ソフトウェア１０１を取得する（ステップＳ１１）。そして、第一の演算部１０２は、取得したソフトウェアを演算処理して、ソフトウェアに基づいた制御などを実行する（ステップＳ１２）。
【0025】
ここで、第一の演算部１０２は、ステップＳ１２で演算処理した際のリソース使用量情報１０３を出力する（ステップＳ１３）。このステップＳ１１～Ｓ１３の処理が、第一の演算部１０２が稼働中に繰り返される。
【0026】
［リソース使用量と最悪リソース使用量の例］
図５は、本例におけるリソース使用量情報１０３の一例を示す図である。リソース使用量情報１０３は、第一の演算部１０２がソフトウェアを実行中の情報であり、演算処理中に随時変化する。
ここでのリソース使用量情報１０３は、第一の演算部１０２にて既存ソフトウェア１０１を演算処理した場合のＣＰＵ負荷率の情報Ｄ１２と、第一の演算部１０２にて既存ソフトウェア１０１を演算処理した場合のレイテンシの情報Ｄ１３を含む。
図５は、本例におけるリソース使用量情報１０３の一例を示す図である。リソース使用量情報１０３は、第一の演算部１０２がソフトウェアを実行中の情報であり、演算処理中に随時変化する。
ここでのリソース使用量情報１０３は、第一の演算部１０２にて既存ソフトウェア１０１を演算処理した場合のＣＰＵ負荷率の情報Ｄ１２と、第一の演算部１０２にて既存ソフトウェア１０１を演算処理した場合のレイテンシの情報Ｄ１３を含む。
【0027】
ＣＰＵ負荷率の情報Ｄ１２は、演算中のＣＰＵ負荷率として示されている。
ここでは、例えば、センサフュージョンのＣＰＵ負荷率は２０％、オブジェクトトラッキングのＣＰＵ負荷率は２５％、ローカルマップ作成のＣＰＵ負荷率は１５％、軌道生成のＣＰＵ負荷率は１２％、制御値算出のＣＰＵ負荷率は１０％とされている。
また、ＣＰＵ負荷率の情報Ｄ１２には、これらの合計のＣＰＵ負荷率（ここでは８２％）の情報も含まれている。
ここでは、例えば、センサフュージョンのＣＰＵ負荷率は２０％、オブジェクトトラッキングのＣＰＵ負荷率は２５％、ローカルマップ作成のＣＰＵ負荷率は１５％、軌道生成のＣＰＵ負荷率は１２％、制御値算出のＣＰＵ負荷率は１０％とされている。
また、ＣＰＵ負荷率の情報Ｄ１２には、これらの合計のＣＰＵ負荷率（ここでは８２％）の情報も含まれている。
【0028】
レイテンシの情報Ｄ１３には、演算中の処理時間がレイテンシとして示されている。
例えば、センサフュージョンのレイテンシは４０ms、オブジェクトトラッキングのレイテンシは４０ms、ローカルマップ作成のレイテンシは４０ms、軌道生成のレイテンシは１０ms、制御値算出のレイテンシは１０msとされている。
また、レイテンシの情報Ｄ１３には、これらの合計のレイテンシ（ここでは１４０ms）の情報も含まれている。
例えば、センサフュージョンのレイテンシは４０ms、オブジェクトトラッキングのレイテンシは４０ms、ローカルマップ作成のレイテンシは４０ms、軌道生成のレイテンシは１０ms、制御値算出のレイテンシは１０msとされている。
また、レイテンシの情報Ｄ１３には、これらの合計のレイテンシ（ここでは１４０ms）の情報も含まれている。
【0029】
図６は、リソース監視部１０４で監視して得られた最悪リソース使用量情報１０６の一例を示す図である。
最悪リソース使用量情報１０６は、第一の演算部１０２にて既存ソフトウェア１０１を演算処理した場合の最悪ＣＰＵ負荷率の情報Ｄ１４と、第一の演算部１０２にて既存ソフトウェア１０１を演算処理した場合の最悪レイテンシの情報Ｄ１５を含む。
最悪リソース使用量情報１０６は、第一の演算部１０２にて既存ソフトウェア１０１を演算処理した場合の最悪ＣＰＵ負荷率の情報Ｄ１４と、第一の演算部１０２にて既存ソフトウェア１０１を演算処理した場合の最悪レイテンシの情報Ｄ１５を含む。
【0030】
これらの最悪ＣＰＵ負荷率の情報Ｄ１４と最悪レイテンシの情報Ｄ１５は、次の図７に示すリソース監視処理によって、図５に示すＣＰＵ負荷率の情報Ｄ１２およびレイテンシの情報Ｄ１３として得られた値の最悪値（最大値）となるようにしている。
例えば、図６のオブジェクトトラッキングの最悪ＣＰＵ負荷率は２３％、ローカルマップ作成の最悪ＣＰＵ負荷率は１８％となり、合計の最悪ＣＰＵ負荷率も８３％となっており、図５に示すＣＰＵ負荷率とは相違している。
例えば、図６のオブジェクトトラッキングの最悪ＣＰＵ負荷率は２３％、ローカルマップ作成の最悪ＣＰＵ負荷率は１８％となり、合計の最悪ＣＰＵ負荷率も８３％となっており、図５に示すＣＰＵ負荷率とは相違している。
【0031】
［リソース監視処理］
図７は、この図５および図６に示す情報を得るためのリソース監視部１０４による処理手順を示したフローチャートである。
まず、リソース監視部１０４は、第一の演算部１０２からリソース使用量情報１０３を入手する（ステップＳ２１）。また、リソース監視部１０４は、リソース情報保持部１０５が保持した最悪リソース使用量情報１０６を入手する（ステップＳ２２）。
図７は、この図５および図６に示す情報を得るためのリソース監視部１０４による処理手順を示したフローチャートである。
まず、リソース監視部１０４は、第一の演算部１０２からリソース使用量情報１０３を入手する（ステップＳ２１）。また、リソース監視部１０４は、リソース情報保持部１０５が保持した最悪リソース使用量情報１０６を入手する（ステップＳ２２）。
【0032】
次に、リソース監視部１０４は、ステップＳ２１で入手したリソース使用量情報１０３で示される各ソフトウェアのリソースの値が、ステップＳ２２で入手した最悪リソース使用量情報１０６の値より大きいか否かを判定する（ステップＳ２３）。
ステップＳ２３での判定結果が、最悪リソース使用量情報１０６の値より大きい場合（ステップＳ２３のＹＥＳ）、リソース監視部１０４は、最悪リソース使用量情報１０６の値を、リソース使用量情報１０３の値に基づき更新する（ステップＳ２４）。そして、リソース監視部１０４は、更新した最悪リソース使用量情報１０６の値を出力して、リソース情報保持部１０５に保持させる（ステップＳ２５）。
ステップＳ２３での判定結果が、最悪リソース使用量情報１０６の値より大きい場合（ステップＳ２３のＹＥＳ）、リソース監視部１０４は、最悪リソース使用量情報１０６の値を、リソース使用量情報１０３の値に基づき更新する（ステップＳ２４）。そして、リソース監視部１０４は、更新した最悪リソース使用量情報１０６の値を出力して、リソース情報保持部１０５に保持させる（ステップＳ２５）。
【0033】
また、ステップＳ２３での判定結果が、最悪リソース使用量情報１０６の値と同じか小さい場合（ステップＳ２３のＮＯ）、リソース監視部１０４は、最悪リソース使用量情報の値を更新せずにリソース監視処理を終了する。
リソース監視部１０４は、この図７のフローチャートの処理を繰り返し実行する。
リソース監視部１０４は、この図７のフローチャートの処理を繰り返し実行する。
【0034】
なお、図６に示す最悪リソース使用量情報Ｄ１４，Ｄ１５が設定されて、図５に示すリソース使用量情報Ｄ１２，Ｄ１３の情報が入手された場合には、オブジェクトトラッキングのＣＰＵ負荷率２５％が、最悪ＣＰＵ負荷率２３％よりも大きな値になる。したがって、リソース監視部１０４は、ステップＳ２４で最悪ＣＰＵ負荷率を２５％に更新する。
【0035】
［新ソフトウェアのリソース使用量］
図８は、本例に新ソフトウェアリソース使用量情報２の一例を示す図である。
ここでは、ソフトウェアアップデートにより既存ソフトウェア１０１の中のフュージョン処理が更新される場合を想定している。
図８に示す新ソフトウェアリソース使用量Ｄ１６では、新しくアップデートされるフュージョン機能について、更新後のフュージョンはＣＰＵ負荷率が４０％、レイテンシが４０msになることが示されている。
図８は、本例に新ソフトウェアリソース使用量情報２の一例を示す図である。
ここでは、ソフトウェアアップデートにより既存ソフトウェア１０１の中のフュージョン処理が更新される場合を想定している。
図８に示す新ソフトウェアリソース使用量Ｄ１６では、新しくアップデートされるフュージョン機能について、更新後のフュージョンはＣＰＵ負荷率が４０％、レイテンシが４０msになることが示されている。
【0036】
［アップデート判断処理］
図９は、アップデート判断部１０７の処理手順を示すフローチャートである。
まず、アップデート判断部１０７は、新ソフトウェアリソース使用量情報２を入手する（ステップＳ３１）。この新ソフトウェアリソース使用量情報２の入手は、アップデートを開始する任意のタイミングで行われる。ここでのアップデートを開始する任意のタイミングとは、例えば車両の停車時、車両の駐車時、車両の充電時（電気自動車又は充電可能なハイブリッド車の場合）、車両のユーザインターフェースによる通知時のいずれかのタイミングとすることで、車両の走行中を避けた適切なアップデートが可能になる。
図９は、アップデート判断部１０７の処理手順を示すフローチャートである。
まず、アップデート判断部１０７は、新ソフトウェアリソース使用量情報２を入手する（ステップＳ３１）。この新ソフトウェアリソース使用量情報２の入手は、アップデートを開始する任意のタイミングで行われる。ここでのアップデートを開始する任意のタイミングとは、例えば車両の停車時、車両の駐車時、車両の充電時（電気自動車又は充電可能なハイブリッド車の場合）、車両のユーザインターフェースによる通知時のいずれかのタイミングとすることで、車両の走行中を避けた適切なアップデートが可能になる。
【0037】
そして、アップデート判断部１０７は、リソース情報保持部１０５に保持された最悪リソース使用量情報１０６を入手する（ステップＳ３２）。
次に、アップデート判断部１０７は、新ソフトウェアでアップデートを行った場合に、ハードウェアリソースが枯渇するかどうかを、新ソフトウェアリソース使用量情報２の値と、最悪リソース使用量情報１０６の更新対象ソフトウェア以外のソフトウェアの値とを加算して判断する（ステップＳ３３）。
次に、アップデート判断部１０７は、新ソフトウェアでアップデートを行った場合に、ハードウェアリソースが枯渇するかどうかを、新ソフトウェアリソース使用量情報２の値と、最悪リソース使用量情報１０６の更新対象ソフトウェア以外のソフトウェアの値とを加算して判断する（ステップＳ３３）。
【0038】
例えば、図８に示す新ソフトウェアリソース使用量Ｄ１６（フュージョンのＣＰＵ負荷率４０％、レイテンシ４０ms）のとき、図６に示す最悪リソース使用量情報Ｄ１４，Ｄ１５のフュージョンの値を、新ソフトウェアリソース使用量Ｄ１６で更新して合計値を求める。この合計値が一定のＣＰＵ負荷率（例えば１００％あるいは余裕を持たせた９５％などの）を超えた場合、あるいはレイテンシの合計が処理周期を超えた場合、アップデート判断部１０７は、ハードウェアリソースが枯渇すると判断する。なお、枯渇すると判断するＣＰＵ負荷率は、余裕を持たせた９５％や９０％などの１００％よりも低い値としてもよい。同様に、レイテンシについても処理周期よりも短い時間としてもよい。
【0039】
そして、ステップＳ３３の判断で、ハードウェアリソースが枯渇すると判断したとき（ステップＳ３３のＹＥＳ）、アップデート判断部１０７は、アップデート判断結果情報１０８として、アップデートできないことを示す「ＮＧ」を出力する（ステップＳ３４）。
さらに、アップデート判断部１０７は、配置変更依頼情報１０９を出力して（ステップＳ３４）、アップデート判断処理を終了する。
さらに、アップデート判断部１０７は、配置変更依頼情報１０９を出力して（ステップＳ３４）、アップデート判断処理を終了する。
【0040】
また、ステップＳ３３の判断で、ハードウェアリソースが枯渇しないと判断したとき（ステップＳ３３のＮＯ）、アップデート判断部１０７は、アップデート判断結果情報１０８として、アップデート可能を示す「ＯＫ」を出力して（ステップＳ３６）、アップデート判断処理を終了する。
【0041】
図１０は、アップデート判断結果情報１０８の例を示す。ここでは、アップデート判断結果「ＮＧ」の情報Ｄ１７を示す。この図１０に示すアップデート判断結果情報１０８の場合には、配置変更依頼が行われる。一方、図示は省略するがアップデート判断結果「ＯＫ」の場合には、アップデート実行部１１０でのアップデートが実行される。
【0042】
［アップデート実行処理］
図１１は、アップデート実行部１１０によるアップデート実行時の処理手順を示すフローチャートである。
アップデート実行部１１０は、アップデート判断結果情報１０８を入手する（ステップＳ４１）。そして、アップデート実行部１１０は、入手した判断結果が「ＯＫ」であるか否かを判断する（ステップＳ４２）。このステップＳ４２の判断で、判断結果「ＯＫ」の場合には（ステップＳ４２のＹＥＳ）、アップデート実行部１１０は、用意された新ソフトウェアによるアップデートを実行して（ステップＳ４３）、アップデート実行処理を終了する。一方、ステップＳ４２の判断で、判断結果「ＮＧ」の場合には（ステップＳ４２のＮＯ）、アップデートを実行せずに、アップデート実行処理を終了する。
図１１は、アップデート実行部１１０によるアップデート実行時の処理手順を示すフローチャートである。
アップデート実行部１１０は、アップデート判断結果情報１０８を入手する（ステップＳ４１）。そして、アップデート実行部１１０は、入手した判断結果が「ＯＫ」であるか否かを判断する（ステップＳ４２）。このステップＳ４２の判断で、判断結果「ＯＫ」の場合には（ステップＳ４２のＹＥＳ）、アップデート実行部１１０は、用意された新ソフトウェアによるアップデートを実行して（ステップＳ４３）、アップデート実行処理を終了する。一方、ステップＳ４２の判断で、判断結果「ＮＧ」の場合には（ステップＳ４２のＮＯ）、アップデートを実行せずに、アップデート実行処理を終了する。
【0043】
［配置変更依頼の例］
図１２は、本例の配置変更依頼情報１０９の一例を示す図である。
図１２の例の配置変更依頼の情報Ｄ１９には、制御値算出のソフトウェアのＣＰＵ負荷率情報（１０％）とレイテンシ情報（１０ms）を含む配置を変更するソフトウェアとして制御値算出が記載されている。
なお、ここでの配置を変更するソフトウェアは、新ソフトウェアにアップデートした場合に、ＣＰＵ負荷率やレイテンシが、ハードウェアリソースが枯渇しないようにするために、アップデート判断部１０７などで選択されるものである。すなわち、いずれのソフトウェアを別の演算部で実行させるように配置変更依頼するかは、新ソフトウェアの実行時に伴う第一の演算部１０２と、別の演算部（第二の演算部３）とのレイテンシを考慮して判断される。
図１２は、本例の配置変更依頼情報１０９の一例を示す図である。
図１２の例の配置変更依頼の情報Ｄ１９には、制御値算出のソフトウェアのＣＰＵ負荷率情報（１０％）とレイテンシ情報（１０ms）を含む配置を変更するソフトウェアとして制御値算出が記載されている。
なお、ここでの配置を変更するソフトウェアは、新ソフトウェアにアップデートした場合に、ＣＰＵ負荷率やレイテンシが、ハードウェアリソースが枯渇しないようにするために、アップデート判断部１０７などで選択されるものである。すなわち、いずれのソフトウェアを別の演算部で実行させるように配置変更依頼するかは、新ソフトウェアの実行時に伴う第一の演算部１０２と、別の演算部（第二の演算部３）とのレイテンシを考慮して判断される。
【0044】
［配置変更依頼の送信処理］
図１３は、本例のソフトウェア配置変更依頼送受信部１１１の処理手順を示すフローチャートである。
まず、ソフトウェア配置変更依頼送受信部１１１は、配置変更依頼情報１０９を入手する（ステップＳ５１）。そして、ソフトウェア配置変更依頼送受信部１１１は、入手した配置変更依頼情報１０９を、別の車両制御装置の第二の演算部３に出力して（ステップＳ５２）、配置変更依頼の送信処理を終了する。
図１３は、本例のソフトウェア配置変更依頼送受信部１１１の処理手順を示すフローチャートである。
まず、ソフトウェア配置変更依頼送受信部１１１は、配置変更依頼情報１０９を入手する（ステップＳ５１）。そして、ソフトウェア配置変更依頼送受信部１１１は、入手した配置変更依頼情報１０９を、別の車両制御装置の第二の演算部３に出力して（ステップＳ５２）、配置変更依頼の送信処理を終了する。
【0045】
なお、配置変更依頼を受信した第二の演算部３は、図１の構成と同様の構成になっており、配置変更依頼が行われたソフトウェアを実行した場合に、ハードウェアリソースが枯渇しないか否かを判断する。そして、第二の演算部３は、その結果で配置変更依頼を受ける場合に、ソフトウェア配置変更依頼送受信部１１１に変更依頼ＯＫの返信を行う。
また、該当する配置変更を行うソフトウェアの情報（プログラムデータ）も、第一の演算部１０２を有する車両制御装置１から、第二の演算部３を有する車両制御装置に転送される。あるいは、ソフトウェアのプログラムデータは、第一の演算部１０２を有する車両制御装置１の記憶部が保持したまま、第二の演算部３を有する車両制御装置は、該当するプログラムデータを、ネットワークＮＷを経由して読み出して実行してもよい。
また、該当する配置変更を行うソフトウェアの情報（プログラムデータ）も、第一の演算部１０２を有する車両制御装置１から、第二の演算部３を有する車両制御装置に転送される。あるいは、ソフトウェアのプログラムデータは、第一の演算部１０２を有する車両制御装置１の記憶部が保持したまま、第二の演算部３を有する車両制御装置は、該当するプログラムデータを、ネットワークＮＷを経由して読み出して実行してもよい。
【0046】
［ソフトウェアの配置変更の例］
図１４および図１５は、ソフトウェアのアップデート前後のソフトウェア配置の違いを示す図である。
例えば、図１４に示すように、第一の演算部１０２が、フュージョンＳＷ１、オブジェクトトラッキングＳＷ２、ローカルマップ作成ＳＷ３、軌道生成ＳＷ４、および制御値算出ＳＷ５の各ソフトウェアを実行する構成になっており、第二の演算部３はその他のソフトウェアを実行する構成になっているものとする。
図１４および図１５は、ソフトウェアのアップデート前後のソフトウェア配置の違いを示す図である。
例えば、図１４に示すように、第一の演算部１０２が、フュージョンＳＷ１、オブジェクトトラッキングＳＷ２、ローカルマップ作成ＳＷ３、軌道生成ＳＷ４、および制御値算出ＳＷ５の各ソフトウェアを実行する構成になっており、第二の演算部３はその他のソフトウェアを実行する構成になっているものとする。
【0047】
この状態で、例えばフュージョンＳＷ１が新ソフトウェアのフュージョンＳＷ１′にアップデートされたとする。ここで、そのままでは第一の演算部１０２のハードウェアリソースが枯渇すると判断された場合に、図１５に示すように配置変更が行われる。
すなわち、図１５に示すように、フュージョンＳＷ１′、オブジェクトトラッキングＳＷ２、ローカルマップ作成ＳＷ３、および軌道生成ＳＷ４が、第一の演算部１０２で実行される。そして、制御値算出ＳＷ５が第二の演算部３で実行されるようになる。
すなわち、図１５に示すように、フュージョンＳＷ１′、オブジェクトトラッキングＳＷ２、ローカルマップ作成ＳＷ３、および軌道生成ＳＷ４が、第一の演算部１０２で実行される。そして、制御値算出ＳＷ５が第二の演算部３で実行されるようになる。
【0048】
この図１５の例では、新ソフトウェアであるフュージョンＳＷ１′は、第一の演算部１０２で行うようにしたが、逆に、新ソフトウェアであるフュージョンＳＷ１′を第二の演算部３で実行するようにしてもよい。あるいは、アップデートに関係した全てのソフトウェアを、第二の演算部３で実行するようにしてもよい。また、新ソフトウェアであるフュージョンＳＷ１′の一部を第一の演算部１０２で行うようにし、フュージョンＳＷ１′の残りの一部を第二の演算部３で実行するようにしてもよい。
いずれのソフトウェアを第二の演算部３で実行させるかは、新ソフトウェアの実行時に伴う第一の演算部１０２と第二の演算部３とのレイテンシを考慮して行われる。
いずれのソフトウェアを第二の演算部３で実行させるかは、新ソフトウェアの実行時に伴う第一の演算部１０２と第二の演算部３とのレイテンシを考慮して行われる。
【0049】
以上説明した処理が行われることで、本例の車両制御装置により、ソフトウェアの処理時のレイテンシを考慮しつつ、複数の演算部の間でソフトウェア配置を変更する処理が行われる。したがって、ソフトウェアのアップデートによって、１つの演算部ではハードウェアリソースが枯渇する場合であっても、別の演算部と協調してアップデートが行われ、適切にソフトウェアのアップデートが実現できるようになる。
【0050】
また、アップデート判断部１０７によるアップデートの可否の判断として、ＣＰＵ負荷率とレイテンシとから判断するようにしたため、比較的簡単にリソース使用状況を判断でき、アップデートの可否の判断が少ない演算で簡単に行える効果を有する。なお、ＣＰＵ負荷率とレイテンシとからアップデートの可否を判断するのは一例であり、ＣＰＵ負荷率とレイテンシの他に、メモリ使用量を加えてもよい。ＣＰＵ負荷率とレイテンシとメモリ使用量とからリソース使用状況を判断することで、リソース使用状況をより的確に判断できるようになる。
あるいは、アップデート判断部１０７は、ＣＰＵ負荷率とレイテンシとメモリ使用量のいずれか１つから、リソース使用状況を判断してもよい。これによりリソース使用状況を判断する際に判定する数値が一つでよく、簡単にリソース使用状況を判断できるようになる。
あるいは、アップデート判断部１０７は、ＣＰＵ負荷率とレイテンシとメモリ使用量のいずれか１つから、リソース使用状況を判断してもよい。これによりリソース使用状況を判断する際に判定する数値が一つでよく、簡単にリソース使用状況を判断できるようになる。
【0051】
また、図１５に示したように、新ソフトウェアについては第一の演算部１０２で行うようにして、既存ソフトウェアの一部を第二の演算部３で行うように構成変更を行うようにしたことで、各演算部のハードウェア資源を有効に使ったアップデートが可能になる。この場合の配置変更の判断についても、ＣＰＵ負荷率、レイテンシ、メモリ使用量などのリソース使用状況に基づいて行うことで、最適な配置変更ができるようになる。
【0052】
［変形例］
なお、ここまで説明した実施の形態例は、本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。
例えば、車両制御装置１がアップデートを実行するタイミングについては、車両の任意のタイミングに行うことが可能である。すなわち、新ソフトウェアの全構成を第一の演算部１０２においてアップデート可能か、あるいは新ソフトウェアの一部構成を第二の演算部３に配置変更するかを、リソース情報保持部１０５の保持情報の一部である最悪リソース使用量情報１０６（中央処理ユニットの負荷率、メモリ使用量、レイテンシの少なくともいずれか１つ）に基づいて判断することを、車両の任意のタイミングで行うことで、適切なアップデートが可能になる。
ここでの車両の任意のタイミングとは、例えば車両の停車時、車両の駐車時、車両の充電時（電気自動車又は充電可能なハイブリッド車の場合）、車両のユーザインターフェースによる通知時のいずれかのタイミングとすることで、車両の走行中を避けた適切なアップデートが可能になる。
なお、ここまで説明した実施の形態例は、本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。
例えば、車両制御装置１がアップデートを実行するタイミングについては、車両の任意のタイミングに行うことが可能である。すなわち、新ソフトウェアの全構成を第一の演算部１０２においてアップデート可能か、あるいは新ソフトウェアの一部構成を第二の演算部３に配置変更するかを、リソース情報保持部１０５の保持情報の一部である最悪リソース使用量情報１０６（中央処理ユニットの負荷率、メモリ使用量、レイテンシの少なくともいずれか１つ）に基づいて判断することを、車両の任意のタイミングで行うことで、適切なアップデートが可能になる。
ここでの車両の任意のタイミングとは、例えば車両の停車時、車両の駐車時、車両の充電時（電気自動車又は充電可能なハイブリッド車の場合）、車両のユーザインターフェースによる通知時のいずれかのタイミングとすることで、車両の走行中を避けた適切なアップデートが可能になる。
【0053】
また、上述した実施の形態例では、車両制御装置の外部にある別の車両制御装置の演算部とのソフトウェア配置変更を例にして説明したが、演算部の配置箇所には上述した実施の形態例に限定されるものではなく、本発明は、複数の演算部が搭載されたシステムに広く適用可能である。
また、図１，図２に示す構成図では、制御線や情報線は説明上必要と考えられるものだけを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。
また、図４以降に示すフローチャートの処理の流れについても一例であり、処理結果が同じであれば、一部の処理順序を変えたり、複数の処理を同時に実行したりしてもよい。
また、図１，図２に示す構成図では、制御線や情報線は説明上必要と考えられるものだけを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。
また、図４以降に示すフローチャートの処理の流れについても一例であり、処理結果が同じであれば、一部の処理順序を変えたり、複数の処理を同時に実行したりしてもよい。
【0054】
また、本発明の車両制御装置で行われる処理は、プログラム（ソフトウェア）の実行により行われるものであり、例えば既存の情報処理装置（コンピュータ）に、実施の形態例で説明した処理を実行するプログラムを実装することで、本発明の車両制御装置として機能させてもよい。この場合のプログラムの情報は、メモリや、ハードディスク、ＳＳＤ(Solid State Drive)、ＩＣカード、ＳＤカード光ディスク等の各種記録媒体に置くことができる。
また、車両制御装置は、図２に示す構成では、ＣＰＵの制御で実行される情報処理装置（コンピュータ）で構成した例としたが、車両制御装置が行う機能の一部又は全部を、ＦＰＧＡ（Field Programmable Gate Array）やＡＳＩＣ（Application Specific Integrated Circuit）などの専用のハードウェアによって実現してもよい。
また、車両制御装置は、図２に示す構成では、ＣＰＵの制御で実行される情報処理装置（コンピュータ）で構成した例としたが、車両制御装置が行う機能の一部又は全部を、ＦＰＧＡ（Field Programmable Gate Array）やＡＳＩＣ（Application Specific Integrated Circuit）などの専用のハードウェアによって実現してもよい。
【符号の説明】
【0055】
１，１ａ，１ｂ，１ｃ，１ｄ…車両制御装置、２…ソフトウェアリソース使用量情報、３…第二の演算部、１１…ＣＰＵ、１２…ワークメモリ、１３…記憶部、１４…インターフェース、１０１…既存ソフトウェア保持部、１０２…第一の演算部、１０３…リソース使用量情報、１０４…リソース監視部、１０５…リソース情報保持部、１０６…最悪リソース使用量情報、１０７…アップデート判断部、１０８…アップデート判断結果情報、１０９…配置変更依頼情報、１１０…アップデート実行部、１１１…ソフトウェア配置変更依頼送受信部
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】