WO2024018755A1

WO2024018755A1 - 車載装置、サーバ装置、リソース制御方法、リソース制御支援方法、およびコンピュータプログラム

Info

Publication number: WO2024018755A1
Application number: PCT/JP2023/019598
Authority: WO
Inventors: 明紘小川
Original assignee: 住友電気工業株式会社; 株式会社オートネットワーク技術研究所; 住友電装株式会社
Priority date: 2022-07-21
Filing date: 2023-05-26
Publication date: 2024-01-25

Abstract

車載装置は、外部装置と通信する通信部と、通信部を介して、自車両以外の車両である他車両が自車両の走行予定エリアを走行したときの、当該他車両のリソース消費量の実績情報を取得する情報取得部と、情報取得部が取得した実績情報に基づいて、走行予定エリアを自車両が走行した場合に、自車両の走行に伴って時間的に変動するリソース消費量を推定する推定部と、推定部の推定結果に応じて、所定のアプリケーションソフトウェアの実行期間を所定の期間に割り当てることにより、リソース消費を制御するリソース制御部とを含む。

Description

車載装置、サーバ装置、リソース制御方法、リソース制御支援方法、およびコンピュータプログラム

　本開示は、車載装置、サーバ装置、リソース制御方法、リソース制御支援方法、およびコンピュータプログラムに関する。本開示は、２０２２年７月２１日出願の日本出願第２０２２－１１６０４７号に基づく優先権を主張し、前記日本出願に記載された全ての記載内容を援用するものである。

　高速大容量の通信が可能となる次世代のコネクティッドサービスにおいては、車両と車外装置との間における通信データ量が増大する。これに伴い、車両に搭載される車載装置において、リソース消費量（通信リソースまたは計算リソース等の消費量）の時間的な変動幅も増大する。

　こうした状況においては、通信データ量がピークとなる高負荷時に許容遅延時間を満たせないサービスが発生し得る。高負荷に対応可能な高性能なプロセッサを車載装置に搭載すれば、高負荷時においても、許容遅延時間を満たせないサービスの発生を抑制できるかもしれない。しかし、その場合、オーバスペックとなって車載装置のコストが増大する。

　高負荷時にシステムの応答性の低下を抑制する技術として、後掲の特許文献１は、タスクを処理するプロセッサコアを動的に割り付けて負荷分散する自動車用電子制御装置に関する技術を提案する。特許文献１の自動車用電子制御装置は、複数のプロセッサコアが集積されたマルチコアプロセッサを搭載する。この自動車用電子制御装置は、運転状態の変化に応じた割込処理に係るタスクが発生した場合、そのタスクについて、複数のプロセッサコアの負荷状況に応じて負荷分散する第１の分散処理を実行する。自動車用電子制御装置はさらに、エンジン回転数が所定値以下であるときに、運転状態の変化を予測してその予測結果に影響を受けるタスクについて、複数のプロセッサコアの負荷状況に応じて負荷分散する第２の分散処理を実行する。

特開２０１９－１０９７４４号公報

　本開示のある局面に係る車載装置は、車両に搭載される車載装置であって、外部装置と通信する通信部と、通信部を介して、自車両以外の車両である他車両が自車両の走行予定エリアを走行したときの、他車両のリソース消費量の実績情報を取得する情報取得部と、情報取得部が取得した実績情報に基づいて、走行予定エリアを自車両が走行した場合に、自車両の走行に伴って時間的に変動するリソース消費量を推定する推定部と、推定部の推定結果に応じて、所定のアプリケーションソフトウェアの実行期間を所定の期間に割り当てることにより、リソース消費を制御するリソース制御部とを含む。

　本開示は、このような特徴的な構成を含む車載装置、サーバ装置、リソース制御方法、リソース制御支援方法、およびコンピュータプログラムとして実現できるだけではなく、本車載装置、または本サーバ装置が実行する特徴的なステップをコンピュータに実行させるためのプログラムを記録した記憶媒体として実現することもできる。さらに、車載装置またはサーバ装置を含むその他のシステムまたは装置として実現することもできる。

図１は、第１の実施の形態に係るシステムの全体構成を説明するための図である。図２は、図１に示す車載装置が搭載された車両を説明するための図である。図３は、動的マップを説明するための図である。図４は、図１に示す車載装置において実行されるリソース制御を説明するための図である。図５は、図１に示す車載装置において実行されるリソース制御を説明するための図である。図６は、図１に示すサーバ装置におけるリソース消費量実績地図の作成方法を説明するための図である。図７は、リソース消費量実績地図の内容の一例を示す図である。図８は、図１に示す車載装置の機能的構成の一例を示すブロック図である。図９は、図８に示す車載装置（ＧＷ（Ｇａｔｅｗａｙ）装置）のハードウェア構成の一例を示すブロック図である。図１０は、図１に示すサーバ装置のハードウェア構成の一例を示すブロック図である。図１１は、図１０に示すサーバ装置の機能的構成の一例を示すブロック図である。図１２は、第１の実施の形態に係る車載装置において実行されるプログラムの制御構造の一例を示すフローチャートである。図１３は、第１の実施の形態に係るサーバ装置において実行されるプログラムの制御構造の一例を示すフローチャートである。図１４は、第１の変形例に係るサーバ装置において実行されるプログラムの制御構造の一例を示すフローチャートである。図１５は、第２の変形例に係る車載装置において実行されるプログラムの制御構造の一例を示すフローチャートである。図１６は、第２の変形例に係るサーバ装置において実行されるプログラムの制御構造の一例を示すフローチャートである。図１７は、第３の変形例に係る車載装置において実行されるプログラムの制御構造の一例を示すフローチャートである。図１８は、第３の変形例に係るサーバ装置において実行されるプログラムの制御構造の一例を示すフローチャートである。図１９は、第４の変形例に係るサーバ装置において実行されるプログラムの制御構造の一例を示すフローチャートである。図２０は、第４の変形例に係る車載装置において実行されるプログラムの制御構造の一例を示すフローチャートである。図２１は、第２の実施の形態に係る車載装置の構成を説明するための図である。図２２は、図２１に示す車載装置（ＧＷ装置）の機能的構成の一例を示すブロック図である。図２３は、第２の実施の形態に係る車載装置において実行されるプログラムの制御構造の一例を示すフローチャートである。図２４は、第３の実施の形態に係るサーバ装置の機能的構成の一例を示すブロック図である。図２５は、第３の実施の形態に係る車載装置（ＧＷ装置）の機能的構成の一例を示すブロック図である。図２６は、第３の実施の形態に係るサーバ装置において実行されるプログラムの制御構造の一例を示すフローチャートである。図２７は、第３の実施の形態に係る車載装置において実行されるプログラムの制御構造の一例を示すフローチャートである。

　［本開示が解決しようとする課題］
　特許文献１に開示の技術においては、運転状態の変化を予測してタスクを複数のプロセッサコアに動的に割り付ける。これにより、運転状態の変化に応じた割込処理により生じる高負荷状態を解消できる。しかし、運転状態の変化からは車外との通信に起因する負荷上昇を予測することは困難である。そのため、特許文献１に開示の技術においては、車外との通信に起因する高負荷時にサービスの応答性が低下するおそれがある。

　本開示は、上記のような課題を解決するためになされたものであり、本開示の１つの目的は、車外との通信に起因する高負荷時においても応答性の低下を抑制することが可能な車載装置、サーバ装置、リソース制御方法、リソース制御支援方法、およびコンピュータプログラムを提供することである。

　［本開示の効果］
　本開示によれば、車外との通信に起因する高負荷時においても応答性の低下を抑制することが可能な車載装置、サーバ装置、リソース制御方法、リソース制御支援方法、およびコンピュータプログラムを提供できる。

　［本開示の実施形態の説明］
　本開示の好適な実施形態を列記して説明する。以下に記載する実施形態の少なくとも一部を任意に組合せてもよい。

　（１）本開示の第１の局面に係る車載装置は、車両に搭載される車載装置であって、外部装置と通信する通信部と、通信部を介して、自車両以外の車両である他車両が自車両の走行予定エリアを走行したときの、他車両のリソース消費量の実績情報を取得する情報取得部と、情報取得部が取得した実績情報に基づいて、走行予定エリアを自車両が走行した場合に、自車両の走行に伴って時間的に変動するリソース消費量を推定する推定部と、推定部の推定結果に応じて、所定のアプリケーションソフトウェアの実行期間を所定の期間に割り当てることにより、リソース消費を制御するリソース制御部とを含む。

　情報取得部は、自車両以外の車両である他車両が自車両の走行予定エリアを走行したときの、当該他車両のリソース消費量の実績情報を取得する。取得した実績情報に基づいて、推定部が、自車両の走行に伴って時間的に変動するリソース消費量を推定する。すなわち、この実績情報に基づいて、走行予定エリアを自車両が走行した場合における車外との通信に起因する負荷上昇を予測する。リソース制御部は、所定のアプリケーションソフトウェアの実行期間を、例えば高負荷時を避けた期間に割り当てることにより、リソース消費を制御する。これにより、車載装置は、車外との通信に起因する高負荷時においても応答性の低下を抑制できる。加えて、高性能なプロセッサを車載装置に搭載することなく、許容遅延時間を満たせないサービスの発生を抑制できる。その結果、車載装置のコスト増大を抑制しつつ、応答性の低下を抑制できる。

　（２）上記（１）において、推定部は、走行予定エリアの走行区間に応じて変動するリソース消費量であって、処理の実行にリアルタイム性が要求されるアプリケーションソフトウェアの実行によるリソース消費量を含むリソース消費量を走行区間毎に推定し、リソース制御部は、推定部の推定結果に応じて、処理の実行にリアルタイム性が要求されないアプリケーションソフトウェアの実行期間を所定の期間に割り当てることにより、リソース消費を制御する構成であってもよい。このように構成すれば、リソースに空きがある期間に、リアルタイム性が要求されないアプリケーションソフトウェアの実行期間を割り当てることができる。すなわち、リアルタイム性が要求されるアプリケーションソフトウェアの実行によりリソース消費量が増大する期間に、リアルタイム性が要求されないアプリケーションソフトウェアが実行されるのを防止できる。これにより、アプリケーションソフトウェアの実行期間を分散できるので、車外との通信に起因する高負荷時において、応答性の低下を容易に抑制できる。なお、アプリケーションソフトウェアにおいてリアルタイム性が要求されるか否かは、例えば、通信における許容遅延時間が所定のしきい値以下か否かに基づいて判定することができる。

　（３）上記（１）または（２）において、外部装置は、複数の他車両からリソース消費量の実績情報を収集し、収集した実績情報に基づいて、走行予定エリアの走行区間にリソース消費実績が設定されたリソース消費量実績地図を作成するサーバ装置を含み、情報取得部は、通信部を介して、サーバ装置からリソース消費量実績地図を実績情報として取得し、推定部は、リソース消費量実績地図に基づいて、走行予定エリアにおける各走行区間のリソース消費量を推定する構成であってもよい。このように構成すれば、自車両の走行に伴って時間的に変動するリソース消費量を容易に推定できる。すなわち、走行予定エリアを自車両が走行した場合における車外との通信に起因する負荷上昇を容易に予測できる。

　（４）上記（１）または（２）において、外部装置は、自車両以外の車両である他車両に搭載された車載装置を含み、情報取得部は、通信部を介して、自車両の走行予定エリアを走行した他車両の車載装置から走行予定エリアにおけるリソース消費量の実績情報を取得し、推定部は、他車両の車載装置から取得したリソース消費量の実績情報に基づいて、走行予定エリアにおける各走行区間のリソース消費量を推定する構成であってもよい。これによっても、自車両の走行に伴って時間的に変動するリソース消費量を容易に推定できる。そのため、車外との通信に起因する高負荷時における応答性の低下を容易に抑制できる。

　（５）上記（１）から（４）のいずれかにおいて、リソース制御部は、リソース使用上限に対する推定部が推定したリソース消費量の割合が所定の値以下となる走行区間の走行予定期間に、処理の実行にリアルタイム性が要求されないアプリケーションソフトウェアの実行期間を割り当てる構成であってもよい。これにより、リアルタイム性が要求されないアプリケーションソフトウェアの実行期間を、高負荷時以外の期間に容易に設定できる。

　（６）上記（５）において、所定の値は、リアルタイム性が要求されないアプリケーションソフトウェアのリソース消費量に基づいて設定される構成であってもよい。これにより、リアルタイム性が要求されないアプリケーションソフトウェアを実行するためのリソースが確保された期間に、当該リアルタイム性が要求されないアプリケーションソフトウェアの実行期間を設定できる。

　（７）上記（１）から（６）のいずれかにおいて、実績情報は、走行予定エリアの走行区間毎に設定され、走行予定エリアを走行した他車両のリソース消費量の実績値が複数段階に量子化された量子化情報を含む構成であってもよい。すなわち、走行予定エリアの走行区間毎に量子化情報が設定され、実績情報は、この量子化情報を含む。これにより、実績情報のデータ量を低減できるので、情報取得部による実績情報の取得が容易になる。

　（８）上記（１）から（７）のいずれかにおいて、情報取得部は、自車両が走行予定エリアに進入する前に実績情報を取得する構成であってもよい。例えば、情報取得部は、走行予定エリアに進入する直前、または数秒前から数分前に実績情報を取得する構成とすることができる。これにより、走行予定エリアに進入する前に、走行予定エリアを自車両が走行した場合における車外との通信に起因する負荷上昇を予測できる。

　（９）上記（１）から（８）のいずれかにおいて、情報取得部は、自車両が走行予定エリアに進入する前に、外部装置に対して実績情報の送信を要求する構成であってもよい。これにより、自車両が走行予定エリアに進入する前に実績情報を取得できる。

　（１０）上記（１）から（９）のいずれかにおいて、実績情報には、当該実績情報が生成された日時を示す時刻情報が付加されており、推定部は、時刻情報が示す日時と現在の日時とを比較し、比較結果に応じて、自車両の走行に伴って時間的に変動するリソース消費量を推定する構成であってもよい。これにより、作成された日時が新しい実績情報を用いてリソース消費量を推定できるので、リソース消費量の推定精度を高めることができる。

　（１１）本開示の第２の局面に係るサーバ装置は、車両に搭載される車載装置と通信可能なサーバ装置であって、複数の車両からリソース消費量の実績情報を収集する情報収集部と、車載装置から走行予定エリアに関する情報を受信し、情報収集部が収集した実績情報に基づいて、走行予定エリアの走行区間にリソース消費実績が設定されたリソース消費量実績地図を作成する実績地図作成部と、走行予定エリアの走行期間において、処理の実行にリアルタイム性が要求されないアプリケーションソフトウェアの実行を推奨する実行推奨期間をリソース消費量実績地図に基づいて抽出する実行期間抽出部と、実行期間抽出部が抽出した実行推奨期間を、走行予定エリアに関する情報を送信した車載装置に対して通知する通知部とを含む。

　サーバ装置は、複数の車両からリソース消費量の実績情報を収集してリソース消費量実績地図を作成する。サーバ装置は、作成したリソース消費量実績地図に基づいて、リアルタイム性が要求されないアプリケーションソフトウェアの実行を推奨する実行推奨期間を抽出し、抽出した実行推奨期間を車載装置に通知する。車載装置は、リアルタイム性が要求されないアプリケーションソフトウェアの実行期間を実行推奨期間に割り当てることにより、アプリケーションソフトウェアの実行期間を分散する。これにより、車載装置は、車外との通信に起因する高負荷時において、応答性の低下を容易に抑制できる。このように、サーバ装置は、リアルタイム性が要求されないアプリケーションソフトウェアの実行推奨期間を車載装置に通知することにより、車載装置に対して、車外との通信に起因する高負荷時に応答性の低下を抑制できるようにすることができる。

　本開示の他の局面に係るサーバは、車両に搭載される車載装置と通信可能なサーバ装置であって、複数の車両からリソース消費量の実績情報を収集する情報収集部と、情報収集部が収集した実績情報に基づいて、所定のエリアの走行区間にリソース消費実績が設定されたリソース消費量実績地図を作成する実績地図作成部と、実績地図作成部が作成したリソース消費量実績地図を車載装置に配信する配信部とを含む。サーバ装置は、リソース消費量実績地図を車載装置に配信することにより、車載装置が搭載された車両において、車外との通信に起因する高負荷時において応答性の低下を抑制できるように車載装置を支援できる。

　（１２）本開示の第３の局面に係るリソース制御方法は、車両に搭載される車載装置におけるリソース制御方法であって、車載装置が、外部装置と通信する通信部を介して、自車両以外の車両である他車両が自車両の走行予定エリアを走行したときの、他車両のリソース消費量の実績情報を取得するステップと、車載装置が、取得するステップにおいて取得した実績情報に基づいて、走行予定エリアを自車両が走行した場合に、自車両の走行に伴って時間的に変動するリソース消費量を推定するステップと、車載装置が、推定するステップにおける推定結果に応じて、所定のアプリケーションソフトウェアの実行期間を所定の期間に割り当てることにより、リソース消費を制御するステップとを含む。これにより、車載装置は、車外との通信に起因する高負荷時においても応答性の低下を抑制できる。

　（１３）本開示の第４の局面に係るリソース制御支援方法は、車両に搭載される車載装置と通信可能なサーバ装置において実行され、車両におけるリソース消費の制御を支援するリソース制御支援方法であって、サーバ装置が、複数の車両からリソース消費量の実績情報を収集するステップと、サーバ装置が、車載装置から走行予定エリアに関する情報を受信し、収集するステップにおいて収集した実績情報に基づいて、走行予定エリアの走行区間にリソース消費実績が設定されたリソース消費量実績地図を作成するステップと、サーバ装置が、走行予定エリアの走行期間において、処理の実行にリアルタイム性が要求されないアプリケーションソフトウェアの実行を推奨する実行推奨期間をリソース消費量実績地図に基づいて抽出するステップと、サーバ装置が、抽出するステップにおいて抽出した実行推奨期間を、走行予定エリアに関する情報を送信した車載装置に対して通知するステップとを含む。これにより、車載装置に対して、車外との通信に起因する高負荷時において応答性の低下を抑制できるように支援できる。

　（１４）本開示の第５の局面に係るコンピュータプログラムは、車両に搭載されるコンピュータを、外部装置と通信する通信部、通信部を介して、自車両以外の車両である他車両が自車両の走行予定エリアを走行したときの、他車両のリソース消費量の実績情報を取得する情報取得部、情報取得部が取得した実績情報に基づいて、走行予定エリアを自車両が走行した場合に、自車両の走行に伴って時間的に変動するリソース消費量を推定する推定部、および、推定部の推定結果に応じて、所定のアプリケーションソフトウェアの実行期間を所定の期間に割り当てることにより、リソース消費を制御するリソース制御部として機能させる。これにより、車外との通信に起因する高負荷時に応答性の低下を抑制できる。

　（１５）本開示の第６の局面に係るコンピュータプログラムは、コンピュータを、複数の車両からリソース消費量の実績情報を収集する情報収集部、車載装置から走行予定エリアに関する情報を受信し、情報収集部が収集した実績情報に基づいて、走行予定エリアの走行区間にリソース消費実績が設定されたリソース消費量実績地図を作成する実績地図作成部、走行予定エリアの走行期間において、処理の実行にリアルタイム性が要求されないアプリケーションソフトウェアの実行を推奨する実行推奨期間をリソース消費量実績地図に基づいて抽出する実行期間抽出部、および、実行期間抽出部が抽出した実行推奨期間を、走行予定エリアに関する情報を送信した車載装置に対して通知する通知部として機能させる。これにより、車載装置に対して、車外との通信に起因する高負荷時において応答性の低下を抑制できるように支援できる。

　［本開示の実施形態の詳細］
　本開示の実施形態に係る車載装置、サーバ装置、リソース制御方法、リソース制御支援方法、コンピュータプログラムの具体例を、以下に図面を参照しつつ説明する。なお、以下の実施の形態においては、同一の部品には同一の参照番号を付してある。それらの機能および名称も同一である。したがって、それらについての詳細な説明は繰返さない。

　（第１の実施の形態）
　［全体構成］
　図１を参照して、本実施の形態に係るシステム３０は、車両１００に搭載される車載装置２００と、車載装置２００と通信するサーバ装置５００とを含む。サーバ装置５００は、車両の外部に設置される外部装置（インフラ装置）である。サーバ装置５００はクラウドサーバであってもよいし、エッジサーバであってもよい。サーバ装置５００と通信する車両（車載装置）は１台に限定されず、複数台であってもよい。

　このシステム３０は、車両１００において、車外との通信に起因する負荷上昇を予測し、所定のアプリケーションソフトウェア（以下、「アプリケーションソフトウェア」を単に「アプリ」と呼ぶ。）の実行期間をスケジューリングする。サーバ装置５００は、後述するリソース消費量実績地図を車載装置２００に提供することによって、車載装置２００における負荷上昇の予測を支援する。車載装置２００は、サーバ装置５００から提供されるリソース消費量実績地図に基づいて、車外との通信に起因する負荷上昇を予測し、リソースに空きがある期間に所定のアプリの実行期間を割り当てる。このように、車載装置２００は、アプリの実行期間を分散することによって、車外との通信に起因する高負荷時においても応答性の低下を抑制する。

　図２を参照して、車載装置２００は、本システム３０を構成するサーバ装置５００以外のサーバ装置（インフラ装置５０）とも通信可能である。車載装置２００が搭載される車両１００には、車載装置２００に加えて、ミリ波レーダ１１０、車載カメラ１１２、およびＬｉＤＡＲ（Ｌａｓｅｒ　Ｉｍａｇｉｎｇ　Ｄｅｔｅｃｔｉｏｎ　ａｎｄ　Ｒａｎｇｉｎｇ）１１４等の各種のセンサが搭載される。車載装置２００は、例えば、これらセンサからセンサデータを収集して、インフラ装置５０に無線送信したり、インフラ装置５０から動的マップを含む種々の情報を受信したりする。

　インフラ装置５０は、車両に搭載される車載センサ、路側機に搭載される路側センサ等から送信させるセンサデータを受信して、安全運転支援等に用いる動的マップを作成する。インフラ装置５０は、作成した動的マップを車両に配信する。

　図３を参照して、動的マップ６０は、実空間６２に存在する移動物体を、ＬｉＤＡＲ、カメラ等の多数のセンサを用いて検知し、その属性（大人、子供、車両、二輪車等）を推定し、仮想空間上に予め準備された高精細な道路地図データを用いて作成される。動的マップ６０には、周辺車両および歩行者情報等の動的情報、事故情報および渋滞情報等の準動的情報、交通規制または道路工事の予定情報等の準静的情報、並びに、路面情報および車線情報等（高精度３次元地図情報）の静的情報が含まれる。

　再び図２を参照して、車載装置２００は、動的マップを含む種々の情報をインフラ装置５０から受信することによって、受信した情報に基づいて安全運転支援等の種々の情報を搭乗者に提供する。インフラ装置５０は、必要に応じて、車載装置２００が搭載された車両１００を遠隔にて監視（遠隔監視）したり、当該車両１００を遠隔にて制御（遠隔制御）したりする構成であってもよい。

　車両１００の車載装置２００はインフラ装置５０と繋がることによって、安全運転支援等の種々のサービスを車両１００の搭乗者に提供可能となる。これらのサービスの提供は、車載装置２００においては、当該車載装置２００におけるサービスアプリの実行によって実現される。

　提供されるサービスは、走行エリアの場所的な特性に依存する場合がある。例えば、交差点付近においては、右折車両、歩行者等の死角情報を運転者に提供するために車載装置２００は動的マップをダウンロードする。また例えば、人通りの多い場所、または渋滞している場所等においては、車載装置２００は、自車両にて収集したセンサデータを、動的マップを構築するインフラ装置５０にアップロードする。

　したがって、走行するエリアによっては、インフラ装置５０と通信するサービスアプリが実行されることによって、車外のインフラ装置５０との通信に起因して車両１００におけるリソース消費量が増大する。すなわち、車外との通信が必要なエリアに車両１００が進入するとリソース消費量が増大する。こうした状況においては、車両１００におけるリソース消費量は、単に増大するだけではなく、当該車両１００の走行に伴って時間的に変動する。そこで、このようなエリアを走行する場合に、リソース消費量の時間的な変動を予測できれば、車外との通信に起因する高負荷に対処することが容易となる。

　再び図１を参照して、リソース消費量の時間的な変動を予測するために、本実施の形態においては、上記したリソース消費量実績地図を用いる。リソース消費量実績地図とは、自車両の走行予定エリアを先に走行した先行車両（自車両以外の車両）のリソース消費量実績に基づいて、どの場所（区間）でどの程度のリソースを実際に消費したかを示す地図である。走行予定エリアは、例えば、リソース消費量の時間的な変動が生じる特定のエリアとすることができる。この場合、リソース消費量実績地図を提供するサーバ装置５００は、特定のエリアに対してリソース消費量実績地図を作成し、走行予定エリアとして上記特定のエリアに進入しようとする車両に対して、作成したリソース消費量実績地図を提供するよう構成することができる。

　車載装置２００は、リソース消費量実績地図を参照することにより、リソース消費量の時間的な変動を予測する。加えて、走行予定エリアを走行する際の車両１００の走行速度等から、車載装置２００は、自車両の走行に伴って時間的に変動するリソース消費量を推定する。これにより、リソースに空きがある期間を予測できるので、車載装置２００は、リソースに空きがある期間に所定のアプリの実行期間を割り当てる。所定のアプリは、例えば、処理の実行に時間的な制約を受けないアプリである。

　［サービスアプリの事例］
　車載装置２００において実行される、車外との通信を行うアプリは、処理の実行にリアルタイム性が要求されるリアルタイムアプリ（「高リアルタイムアプリ」ともいう。）と、処理の実行にリアルタイム性が要求されない非リアルタイムアプリとに分類できる。

　リアルタイムアプリは、リアルタイム性が要求されるため、実行タイミングに制約がある。一方、非リアルタイムアプリは、リアルタイム性が要求されないため、実行タイミングに制約がない。このことから、リアルタイムアプリか非リアルタイムアプリかは、リアルタイム性が要求されるか否か、すなわち、実行タイミングに制約があるか否かにより判別できる。具体的には、例えばアプリの許容遅延時間の有無、または許容遅延時間が所定のしきい値以下か否かにより、リアルタイムアプリか非リアルタイムアプリかが判別される。

　リアルタイムアプリは、リソース消費量に応じて、例えば以下の３つのグループに分類できる。
　（１）第１のグループ：リソース消費量（高）
　このグループには、例えば、車両の遠隔制御および遠隔監視、並びに、動的マップ構築のための自車搭載センサのセンサデータをサーバ装置（インフラ装置）にアップロードする処理等を実行するリアルタイムアプリが属する。
　（２）第２のグループ：リソース消費量（中）
　このグループには、例えば、動的情報（死角情報）共有のための動的マップのダウンロード処理（例えば、数百ｍｓ周期）等を実行するリアルタイムアプリが属する。
　（３）第３のグループ：リソース消費量（低）
　このグループには、例えば、プローブ情報のアップロード処理（例えば、数分周期）等を実行するリアルタイムアプリが属する。

　非リアルタイムアプリは、例えば、静的地図更新のためのダウンロード処理、故障診断のための車両情報のアップロード処理等を行うアプリを含む。

　［リソース消費量の推定例］
　図４を参照して、車両１００の車載装置２００は、リソース消費量実績地図に基づいて、走行予定エリア３２における走行区間毎のリソース消費量を推定する。図４において、上段の図は、リソース消費量実績地図を示し、下段の図は、リソース消費量実績地図に基づいて推定したリソース消費量の時間的な変動を示す。

　リソース消費量実績地図において、「リソース消費量：低」の領域は、例えば、プローブ情報のアップロード処理等を行う第３のグループに属するリアルタイムアプリが主として実行された領域であり、「リソース消費量：中」の領域は、例えば、動的マップのダウンロード処理等を行う第２のグループに属するリアルタイムアプリが主として実行された領域であり、「リソース消費量：高」の領域は、例えば、センサデータをアップロードする処理等を行う第１のグループに属するリアルタイムアプリが主として実行された領域であると認識できる。

　車載装置２００は、例えば、自車両において、各グループに属するリアルタイムアプリを実行した場合に必要となるリソース消費量を推定する。リソース消費量の推定は、例えば、消費量の推定対象（対象リソース）毎に行う。消費量の推定対象は、例えば、通信帯域（無線または有線）、プロセッサ、およびメモリ等である。推定したリソース消費量を、リソース消費量実績地図における各領域の走行時間帯に割り当てることにより、走行に伴うリソース消費量の時間的な変動を示す、図４の下段に示す図が得られる。

　［非リアルタイムアプリのスケジューリング］
　図５を参照して、リソース消費量の推定結果より、リソースに空きがある期間を予測することが可能である。例えば、リソース消費量に応じて複数段階（ここでは、一例として、リアルタイムアプリの第１から第３のグループに対応した、「高」、「中」、「低」の３段階）に量子化されている場合、リソース消費量が「中」および「低」の期間をリソースに空きがある期間と予測してもよい。非リアルタイムアプリは、上記したように、実行タイミングに制約がないため、スケジューリングが可能である。そのため、非リアルタイムアプリは、リソースに空きがある期間であると予測された期間にその実行期間が割り当てられる。

　なお、リソースに空きがある期間の予測は、リソース使用上限に対する、推定したリソース消費量の割合に基づいて行ってもよい。具体的には、リソース使用上限に対する、推定したリソース消費量の割合が、所定のしきい値Ｘ［％］以下となる期間をリソースに空きがある期間としてもよい。しきい値Ｘ［％］は例えば５０％とすることができる。しきい値Ｘ［％］の値は、非リアルタイムアプリのリソース消費量に基づいて設定されてもよい。これにより、非リアルタイムアプリを確実に実行できるリソースが残るようにしきい値Ｘ［％］の値が設定される。

　［リソース消費量実績地図の作成］
　図６を参照して、サーバ装置５００は、先行車両から走行エリア（自車両においては走行予定エリア）におけるリアルタイムアプリ毎のリソース消費実績値を収集する。各先行車両は、走行エリア（走行予定エリア）を走行したときの走行実績情報（例えば、位置情報、時刻情報、およびリソース消費量（観測結果）等）をアップロード情報としてサーバ装置５００に送信する。サーバ装置５００は、収集した情報に基づいて、リソース消費量実績地図を作成し、定期（例えば、数分周期）、または不定期に更新する。

　図７は、リソース消費量実績地図の内容の一例を示す図である。図７は、リソース消費量実績地図の内容を表形式にした例を示しているが、表形式でなくてもよい。図７を参照して、リソース消費量実績地図の内容を示すテーブルは、「エリア（区間）」、「リアルタイムアプリ」、「実行期間（ミリ秒）」、「許容遅延（ミリ秒）」、「対象リソース」、「リソース消費量［数値］」、「リソース消費量［判定結果］」、および「備考」の各カラムを含む。

　「エリア（区間）」のカラムには、位置情報にて規定される区間が格納される。「リアルタイムアプリ」のカラムには、各エリア（区間）にて実行されたリアルタイムアプリの識別番号が格納される。「実行期間（ミリ秒）」のカラムには、リアルタイムアプリの実行期間が格納される。「許容遅延（ミリ秒）」のカラムには、リアルタイムアプリの許容遅延時間が格納される。「対象リソース」のカラムには、対象リソースの項目として「通信帯域」、「プロセッサ」、および「メモリ」が格納される。「リソース消費量［数値］」のカラムには、対象リソースの項目毎のリソース消費実績値が格納される。「リソース消費量［判定結果］」のカラムには、リソース消費実績値の結果をＮ段階に量子化した量子化情報が格納される。例えば、リソース消費実績値の結果を３段階に量子化する場合、「高」、「中」、「低」のいずれかが格納される。「備考」のカラムには、必要に応じて付記事項等が格納される。

　図７に示すテーブルは、所定の期間の実績データとして作成される。走行実績情報に含まれる時刻情報は、所定の期間の情報か否かを判別する際に用いられる。なお、図７に示すテーブルに時刻情報のカラムを付加して、各レコードが時刻情報を持つようにしてもよい。さらに、時刻情報と位置情報とから車両の速度情報が算出できるので、図７に示すテーブルに速度情報のカラムを付加して、各レコードが速度情報を持つようにしてもよい。リソース消費量実績地図には、当該リソース消費量実績地図が生成された日時を示す時刻情報が付加されていてもよい。

　サーバ装置５００（図６参照）は、図７に示すテーブルの内容を適宜、統計処理して用いるよう構成されていてもよい。例えば、「リソース消費量［数値］」のカラムに格納される値は、複数の先行車両の観測値を統計処理（平均化）してもよいし、リアルタイムアプリの実行期間による時間変動を統計処理（平均化）してもよい。

　なお、先行車両か否かに関わらず各車両から走行実績情報を収集し、収集した情報から先行車両の情報に相当する情報を抽出してリソース消費量実績地図を作成または更新するようにしてもよい。

　［車載装置２００の構成］
　図８を参照して、車載装置２００は、車内ＧＷ装置２１０、および車外無線装置３００を含む。車両１００には、ＧＷ装置２１０に加えて、各種センサおよび各種ＥＣＵ（Ｅｌｅｃｔｒｏｎｉｃ　Ｃｏｎｔｒｏｌ　Ｕｎｉｔ）等を含む通信ネットワークである車内ネットワーク４００が搭載される。通常、車両には複数の車内ネットワークが搭載される。図８においては、複数の車内ネットワークを代表して車内ネットワーク４００が記載されており、他の車内ネットワークは記載が省略されている。

　ＧＷ装置２１０は、車内ネットワーク４００を含む複数の車内ネットワークを相互に接続して、車内ネットワーク間におけるデータのやりとりを整理する。車内ネットワーク４００は、種々のセンサを含むセンサ群４１０、および種々のＥＣＵを含むＥＣＵ群４２０を含む。車両１００が自動運転機能を持つ場合は、ＥＣＵ群４２０には自動運転ＥＣＵが含まれる。

　ＧＷ装置２１０はさらに、機能部としての情報取得部２２０、リソース管理部２３０、および、協調仲介部２４０を含む。情報取得部２２０は、車外無線装置３００を介して、自車両（車両１００）の走行予定エリアを走行した他車両（先行車両）による走行予定エリアにおけるリソース消費量の実績情報を取得する。すなわち、情報取得部２２０は、車外無線装置３００を介して、自車両（車両１００）以外の車両である他車両が自車両（車両１００）の走行予定エリアを走行したときの、当該他車両のソース消費量の実績情報を取得する。本実施の形態においては、情報取得部２２０は、サーバ装置５００からリソース消費量実績地図を実績情報として取得する。リソース管理部２３０は、自車両のリソース消費量を管理する。リソース管理部２３０は、リソース消費量推定部２３２と、リソース制御部２３４とを含む。リソース消費量推定部２３２は、情報取得部２２０が取得したリソース消費量実績地図に基づいて、走行予定エリアを自車両が走行した場合に、自車両の走行に伴って時間的に変動するリソース消費量を推定する。リソース制御部２３４は、リソース消費量推定部２３２の推定結果に応じて、所定のアプリの実行期間を所定の期間に割り当てる。具体的には、上記したように、リソース制御部２３４は、非リアルタイムアプリの実行期間をリソースに空きがあると予測した期間に割り当てる。

　協調仲介部２４０は、エンドＥＣＵとサーバ装置（インフラ装置）との協調を仲介する機能部（アプリ）である。協調仲介部２４０は、例えば、動的マップの情報を取得、または更新し、エンドＥＣＵ（例えば自動運転ＥＣＵ）に転送する。

　車外無線装置３００は、車外との無線通信を行う複数の無線インターフェイス（以下、「インターフェイス（Ｉｎｔｅｒｆａｃｅ）」を「ＩＦ」と記載する。）を含む。複数の無線ＩＦは、例えば、５Ｇ（第５世代移動通信システム）またはＬＴＥ（Ｌｏｎｇ　Ｔｅｒｍ　Ｅｖｏｌｕｔｉｏｎ）により外部装置（車外装置）とセルラー通信を行うための無線ＩＦ３１０、Ｃ－Ｖ２Ｘ（Ｃｅｌｌｕｌａｒ　Ｖｅｈｉｃｌｅ　ｔｏ　Ｅｖｅｒｙｔｈｉｎｇ）により外部装置との無線通信を行うための無線ＩＦ３２０、およびその他の無線ＩＦ３３０を含む。その他の無線ＩＦ３３０としては、例えばローカル５Ｇが挙げられる。なお、車外無線装置３００に含まれる無線ＩＦはこれらに限定されず、これら以外のものであってもよい。また、車外無線装置３００に含まれる無線ＩＦの数はこれに限定されない。

　無線ＩＦは、各通信方式に対応した種々のものがある。通信方式としては、広域通信としては、セルラー通信（４Ｇ（ＬＴＥ）／５Ｇ）、ＬＰＷＡ（Ｌｏｗ　Ｐｏｗｅｒ　Ｗｉｄｅ　Ａｒｅａ）が知られており、狭域通信としては、ＤＳＲＣ（Ｄｅｄｉｃａｔｅｄ　Ｓｈｏｒｔ　Ｒａｎｇｅ　Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）、Ｃ－Ｖ２Ｘが知られている。さらに広域と狭域との間のローカル通信として、ＷｉＦｉ、ローカル５Ｇ等がある。ローカル５Ｇは、通信事業者以外の企業または自治体が自主運用している点において、セルラー通信の５Ｇとは異なる。

　［車両１００におけるリソース管理対象］
　リソース管理対象（対象リソース）は、通信リソースと、計算リソースとを含む。通信リソースの管理対象は、車内ネットワーク４００とＧＷ装置２１０との間の有線通信帯域、および、車載装置２００と車外装置（例えば、インフラ装置５０等）との通信による無線通信帯域、並びに、中継処理またはエンド処理を含む。計算リソースの管理対象は、プロセッサ、およびメモリを含む。各リソースの観測領域は、通信帯域（有線／無線）は通信リンクであり、プロセッサおよびメモリはアプリ実行領域である。

　［ハードウェア構成］
　《ＧＷ装置２１０》
　図９を参照して、車両１００に搭載されるＧＷ装置２１０はコンピュータ２１２を含む。コンピュータ２１２は、ＧＷ装置２１０全体を制御する制御部２５０と、種々のデータを記憶する記憶装置２６０と、車内ネットワークとの通信を行う車内ネットワーク通信部２７０と、車外無線装置３００との通信を行う通信ＩＦ２８０とを含む。制御部２５０、記憶装置２６０、車内ネットワーク通信部２７０、および通信ＩＦ２８０はいずれもバス２９０に接続されており、相互間のデータ交換はバス２９０を介して行われる。

　制御部２５０は、演算部２５２と、コンピュータ２１２のブートアッププログラム等を記憶するＲＯＭ（Ｒｅａｄ　Ｏｎｌｙ　Ｍｅｍｏｒｙ）２５４と、随時書込読出可能なＲＡＭ（Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｍｅｍｏｒｙ）２５６とを含む。演算部２５２は、演算素子（プロセッサ）として、例えば、ＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）またはＭＰＵ（Ｍｉｃｒｏ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）を含む。記憶装置２６０は、例えばフラッシュメモリ等の不揮発性メモリを含む。ＲＯＭ２５４または記憶装置２６０には、演算部２５２が実行するソフトウェア（コンピュータプログラム）および種々の情報（データ）が記憶されている。

　ＧＷ装置２１０を本開示に係るＧＷ装置２１０の各機能部として機能させるためのコンピュータプログラムは、ＤＶＤ（Ｄｉｇｉｔａｌ　Ｖｅｒｓａｔｉｌｅ　Ｄｉｓｃ）またはＵＳＢ（Ｕｎｉｖｅｒｓａｌ　Ｓｅｒｉａｌ　Ｂｕｓ）メモリ等の所定の記憶媒体に記憶されて流通し、これらからさらに記憶装置２６０に転送される。または、コンピュータプログラムは、車外との無線通信により外部装置からコンピュータ２１２に送信され記憶装置２６０に記憶されてもよい。

　ＧＷ装置２１０の各機能部の機能は、制御部２５０がハードウェアを用いて実行するソフトウェア処理によって実現される。これらの機能の一部または全部が、マイクロコンピュータを含む集積回路によって実現されてもよい。

　車内ネットワーク通信部２７０は、車内ネットワークと通信するためのＩＦを提供する。車内ネットワーク通信部２７０は、例えばＣＡＮ（Ｃｏｎｔｒｏｌｌｅｒ　Ａｒｅａ　Ｎｅｔｗｏｒｋ）等の通信プロトコルに従い、車内ネットワークとの間で通信を行う。車内ネットワーク通信部２７０は、複数の車内ネットワークに対応して複数設けられている。ＧＷ装置２１０（コンピュータ２１２）は、制御部２５０の制御の下で、一の車内ネットワーク通信部にて受信したデータ（メッセージ）を他の車内ネットワーク通信部から送信することによって、車内ネットワーク間におけるデータの中継を行う。通信ＩＦ２８０は、車外無線装置３００と通信するためのＩＦを提供する。

　《サーバ装置５００》
　図１０を参照して、サーバ装置５００は、コンピュータ５１０を含む。コンピュータ５１０は、制御部５２０と、記憶装置５３０と、ネットワークＩＦ５４０とを含む。制御部５２０は、ＣＰＵ５２２、ＧＰＵ（Ｇｒａｐｈｉｃｓ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）５２４、ＲＯＭ５２６、およびＲＡＭ５２８を含む。制御部５２０、記憶装置５３０、およびネットワークＩＦ５４０はいずれもバス５５０に接続されており、相互間のデータ交換はバス５５０を介して行われる。

　記憶装置５３０は、例えばフラッシュメモリまたはハードディスクドライブ等の不揮発性の記憶装置を含む。記憶装置５３０には、ＣＰＵ５２２が実行するためのコンピュータプログラム、および種々の情報が記憶されている。ネットワークＩＦ５４０は他端末との通信を可能とするネットワーク７０への接続を提供する。

　サーバ装置５００は、ネットワーク７０を介して、リソース消費量実績地図を作成するための走行実績情報（例えば、位置情報、時刻情報、およびリソース消費量（観測結果）等）を各先行車両から取得する。サーバ装置５００は、取得した走行実績情報を処理することによって、リソース消費量実績地図を作成する。サーバ装置５００は、作成したリソース消費量実績地図を、ネットワーク７０を介して、車両に配信する。

　サーバ装置５００を本実施の形態に係るサーバ装置５００の各機能部として機能させるためのコンピュータプログラムは、ＤＶＤまたはＵＳＢメモリ等の所定の記憶媒体に記憶されて流通し、これらからさらに記憶装置５３０に転送される。または、コンピュータプログラムは、ネットワーク７０を介して外部装置からコンピュータ５１０に送信され記憶装置５３０に記憶されてもよい。

　[サーバ装置５００の機能的構成]
　図１１を参照して、サーバ装置５００の制御部５２０は、通信制御部５６０、情報収集部５６２、実績地図作成部５６４、および、配信部５６６を機能部として含む。記憶装置５３０は、走行実績情報記憶部５３２、および実績地図記憶部５３４を含む。通信制御部５６０は、外部装置と通信するためにネットワークＩＦ５４０（図１０参照）を制御する。情報収集部５６２は、複数の先行車両から走行実績情報を収集し、走行実績情報記憶部５３２に格納する。実績地図作成部５６４は、走行実績情報記憶部５３２に格納されている走行実績情報を読み出して処理し、リソース消費量実績地図を作成する。実績地図作成部５６４は、作成したリソース消費量実績地図を実績地図記憶部５３４に格納する。実績地図作成部５６４は、新たに収集した走行実績情報に基づいて、リソース消費量実績地図を更新する機能も持つ。配信部５６６は、所定のタイミングにおいて実績地図記憶部５３４からリソース消費量実績地図を読み出して、車両に対して配信する。

　これらの機能は、制御部２５０がハードウェアを用いて実行するソフトウェア処理によって実現される。これらの機能の一部または全部が、マイクロコンピュータを含む集積回路によって実現されてもよい。

　［ソフトウェア構成］
　《車載装置２００》
　図１２を参照して、車外との通信に起因する高負荷時においても応答性の低下を抑制するために、車載装置２００において実行されるコンピュータプログラムの制御構造について説明する。このプログラムは、例えば車外との無線通信の開始に伴い開始する。

　このプログラムは、サーバ装置５００からリソース消費量実績地図を受信するまで待機するステップＳ１０００と、ステップＳ１０００において、サーバ装置５００からリソース消費量実績地図を受信した場合に実行され、以下に説明するステップＳ１０１２を、対象リソースの観測領域毎に全ての対象リソースに対する処理が終了するまで繰返すステップＳ１０１０とを含む。ステップＳ１０１０においては、受信したリソース消費量実績地図に基づいて、走行予定エリアにおけるリアルタイムアプリのリソース消費量を推定するステップＳ１０１２を含む。

　このプログラムはさらに、ステップＳ１０１０の後に実行され、リソース消費量の推定結果に基づいて、非リアルタイムアプリの実行期間をスケジューリングするステップＳ１０２０と、ステップＳ１０２０の後に実行され、ステップＳ１０２０のスケジューリング処理にて設定した実行期間に非リアルタイムアプリを実行するステップＳ１０３０と、ステップＳ１０３０の後に実行され、システム終了の指示がされたか否かを判定し、判定結果に応じて制御の流れを分岐させるステップＳ１０４０とを含む。ステップＳ１０４０において、システム終了の指示「無し」と判定された場合は、制御はステップＳ１０００に戻る。ステップＳ１０４０において、システム終了の指示「有り」と判定された場合は、このプログラムは終了する。

　《サーバ装置５００》
　図１３を参照して、リソース消費量実績地図を作成して車両に配信するために、サーバ装置５００において実行されるコンピュータプログラムの制御構造について説明する。このプログラムは、例えば、サーバ装置５００を管理する管理者の操作により開始する。

　このプログラムは、リソース消費量実績地図を作成するための走行実績情報（例えば、位置情報、時刻情報、およびリソース消費量（観測結果）等）を各車両（先行車両）から収集するステップＳ２０００と、ステップＳ２０００の後に実行され、収集した情報に基づいて、リソース消費量実績地図を作成または更新するステップＳ２０１０と、ステップＳ２０１０の後に実行され、作成または更新したリソース消費量実績地図を車両１００（車載装置２００）に対して配信し、制御をステップＳ２０００に戻すステップＳ２０２０とを含む。

　［動作］
　本実施の形態に係るシステム３０は以下のように動作する。以下においては、リソース消費量の時間的な変動が生じる特定のエリアを走行予定エリアとする場合について説明する。

　図１を参照して、サーバ装置５００は、特定のエリアを走行した各先行車両から走行エリア（特定のエリア）におけるリアルタイムアプリ毎のリソース消費実績値を収集する。具体的には、各先行車両は、走行エリアを走行したときの走行実績情報（例えば、位置情報、時刻情報、およびリソース消費量（観測結果）等）をアップロード情報としてサーバ装置５００に送信する。サーバ装置５００は、各先行車両からのアップロード情報を受信することによって、リソース消費実績値を含む走行実績情報を収集する（図１３のステップＳ２０００）。

　サーバ装置５００は、収集した走行実績情報に基づいてリソース消費量実績地図を作成し（ステップＳ２０１０）、作成したリソース消費量実績地図を車両１００（車載装置２００）に対して配信する（ステップＳ２０２０）。

　車両１００の車載装置２００は、リソース消費量実績地図を受信すると（図１２のステップＳ１０００においてＹＥＳ）、受信したリソース消費量実績地図に基づいて、走行予定エリアを自車両が走行した場合に、自車両の走行に伴って時間的に変動するリソース消費量を推定する（図１２のステップＳ１０１０）。

　図４を参照して、具体的には、車載装置２００は、受信したリソース消費量実績地図に基づいて、走行予定エリアにおけるリアルタイムアプリのリソース消費量を推定する。車載装置２００は、リソース消費量の推定結果に基づいて、非リアルタイムアプリの実行期間をスケジューリングする（図１２のステップＳ１０２０）。図５を参照して、リソース消費量の推定結果に基づいて、リソースに空きがある期間が抽出される。車載装置２００は、リソースに空きがある期間に非リアルタイムアプリの実行期間を割り当てる。車載装置２００は、非リアルタイムアプリの実行期間に当該非リアルタイムアプリによる処理を実行する（図１２のステップＳ１０３０）。

　以上の説明から明らかなように、本実施の形態に係る車載装置２００およびサーバ装置５００は以下に述べる効果を奏する。

　車載装置２００は、自車両の走行予定エリアを走行した他車両（先行車両）による走行予定エリアにおけるリソース消費量の実績情報（本実施の形態においてはリソース消費量実績地図）を取得する。車載装置２００は、取得したリソース消費量実績地図に基づいて、自車両の走行に伴って時間的に変動するリソース消費量を推定する。すなわち、車載装置２００は、このリソース消費量実績地図に基づいて、走行予定エリアを自車両が走行した場合における車外との通信に起因する負荷上昇を予測する。車載装置２００はさらに、所定のアプリ（非リアルタイムアプリ）の実行期間を、例えば高負荷時を避けた期間に割り当てることにより、リソース消費を制御する。これにより、車載装置２００は、車外との通信に起因する高負荷時においても応答性の低下を抑制できる。加えて、高性能なプロセッサを車載装置に搭載することなく、許容遅延時間を満たせないサービスの発生を抑制できる。その結果、車載装置のコスト増大を抑制しつつ、応答性の低下を抑制できる。

　車載装置２００は、走行予定エリアの走行区間に応じて変動する、リアルタイムアプリの実行によるリソース消費量を含むリソース消費量を走行区間毎に推定し、その推定結果に応じて、非リアルタイムアプリの実行期間を所定の期間に割り当てる。これにより、リソースに空きがある期間に、非リアルタイムアプリの実行期間を割り当てることができる。すなわち、リアルタイムアプリの実行によりリソース消費量が増大する期間に、非リアルタイムアプリが実行されるのを防止できる。これにより、アプリの実行期間を分散できるので、車外との通信に起因する高負荷時において、応答性の低下を容易に抑制できる。

　サーバ装置５００は、複数の先行車両からリソース消費実績値（走行実績情報）を収集し、収集した走行実績情報に基づいて、走行予定エリアの走行区間にリソース消費実績が設定されたリソース消費量実績地図を作成する。車載装置２００は、サーバ装置５００から提供されるリソース消費量実績地図を用いることによって、自車両の走行に伴って時間的に変動するリソース消費量を容易に推定できる。

　非リアルタイムアプリの実行期間をスケジューリングする場合、推定したリソース消費量のリソース使用上限に対する割合が所定のしきい値Ｘ［％］以下となる走行区間の走行予定期間に、非リアルタイムアプリの実行期間を割り当てることもできる。この場合、非リアルタイムアプリの実行期間を、高負荷時以外の期間に容易に設定できる。しきい値Ｘ［％］の値は、非リアルタイムアプリのリソース消費量に基づいて設定されてもよい。これにより、非リアルタイムアプリを実行するためのリソースが確保された期間に、当該非リアルタイムアプリの実行期間を設定できる。

　リソース消費量実績地図は、走行予定エリアの走行区間毎に設定され、走行予定エリアを走行した先行車両による走行予定エリアにおけるリソース消費量の実績値が複数段階（本実施の形態においては３段階）に量子化された量子化情報（例えば「高」、「中」、「低」）を含む。これにより、リソース消費量実績地図のデータ量を低減できるので、車載装置２００によるリソース消費量実績地図の取得が容易になる。

　（第１の変形例）
　第１の変形例に係るシステムにおいては、リソース消費量実績地図を配信するサーバ装置が、配信先の車両の現在位置を監視しており、車両が走行予定エリアに進入する前にリソース消費量実績地図を当該車両に対して配信する。サーバ装置は、車両（車載装置）と通信することにより、車両（車載装置）の位置情報を取得する。サーバ装置は、取得した位置情報に基づいて、配信先の車両が走行予定エリアに進入する前か否かを判定する。

　車両の走行予定エリアは、上記した特定のエリアとしてサーバ装置において設定されている。サーバ装置は、走行予定エリアとして設定された特定のエリアに車両が進入する前であるか否かを判定し、判定結果に応じて、当該車両に対してリソース消費量実績地図を配信する。走行予定エリアに進入する前とは、例えば、走行予定エリアに進入する直前、または数秒前、或いは、走行予定エリアに進入する数分前とすることができる。なお、走行予定エリアに進入するまでの時間は、位置情報および車両速度等から算出することが可能である。

　これにより、車両に搭載される車載装置は、走行予定エリアに進入する前に、サーバ装置からリソース消費量実績地図を受信する。車載装置およびサーバ装置のその他の構成は、上記第１の実施の形態と同様である。

　［ソフトウェア構成］
　第１の変形例に係るサーバ装置おいては、図１３に示されるプログラムに代えて、図１４に示されるプログラムが実行される。図１４のプログラムは、図１３のプログラムにおいて、ステップＳ２０１２をさらに含む。図１４のステップＳ２０００、ステップＳ２０１０、およびステップＳ２０２０における処理は、図１４に示される各ステップにおける処理と同じである。以下、異なる部分について説明する。

　図１４を参照して、このプログラムは、ステップＳ２０１０の後に実行され、リソース消費量実績地図を提供する車両（車載装置）が特定のエリア（走行予定エリア）への進入前か否かを判定し、判定結果に応じて制御の流れを分岐させるステップＳ２０１２を含む。ステップＳ２０１２において、進入前ではないと判定された場合は、制御はステップＳ２０００に戻る。ステップＳ２０１２において、進入前であると判定された場合は、制御はステップＳ２０２０に進む。

　このような構成により、車載装置は走行予定エリアに進入する前に、サーバ装置からリソース消費量実績地図をより確実に取得できる。これにより、走行予定エリアに進入する前に、走行予定エリアを自車両が走行した場合における車外との通信に起因する負荷上昇を予測できる。

　第１の変形例におけるその他の効果は、上記第１の実施の形態と同様である。

　（第２の変形例）
　第２の変形例に係るシステムにおいては、車載装置がサーバ装置に対してリソース消費量実績地図の送信を要求する。サーバ装置は、車載装置からの送信要求に応じて、当該送信要求を送信した車載装置に対してリソース消費量実績地図を配信する。車載装置は、例えば、走行予定エリアに進入する前の任意のタイミングにおいてサーバ装置に送信要求を送信する。これにより、車載装置は、自車両が走行予定エリアに進入する前に、サーバ装置からリソース消費量実績地図を受信できる。車載装置およびサーバ装置のその他の構成は、上記第１の実施の形態と同様である。

　［ソフトウェア構成］
　《車載装置》
　第２の変形例に係る車載装置においては、図１２に示されるプログラムに代えて、図１５に示されるプログラムが実行される。図１５のプログラムは、図１２のプログラムにおいて、ステップＳ１１００をさらに含む。図１５のステップＳ１０００からステップＳ１０４０における処理は、図１２に示される各ステップにおける処理と同じである。以下、異なる部分について説明する。

　図１５を参照して、このプログラムは、リソース消費量実績地図を配信するサーバ装置に対して、リソース消費量実績地図の送信を要求するステップＳ１１００を含む。ステップＳ１１００においては、例えば、自車両が走行予定エリアに進入する前の所定のタイミングにおいて、リソース消費量実績地図の送信を要求する送信要求が車載装置からサーバ装置に対して送信される。ステップＳ１１００の処理が終了すると、制御はステップＳ１０００に進む。ステップＳ１０４０において、システム終了の指示「無し」と判定された場合は、制御はステップＳ１１００に戻る。

　《サーバ装置》
　第２の変形例に係るサーバ装置においては、図１３に示されるプログラムに代えて、図１６に示されるプログラムが実行される。図１６のプログラムは、図１３のプログラムにおいて、ステップＳ２０２０に代えて、ステップＳ２０１４およびステップＳ２０２２を含む。図１６のステップＳ２０００およびステップＳ２０１０における処理は、図１３に示される各ステップにおける処理と同じである。以下、異なる部分について説明する。

　図１６を参照して、このプログラムは、ステップＳ２０１０の後に実行され、車載装置から送信要求を受信したか否かを判定し、判定結果に応じて制御の流れを分岐させるステップＳ２０１４と、ステップＳ２０１４において、送信要求を受信したと判定された場合に実行され、当該送信要求を送信した車載装置（車両）に対してリソース消費量実績地図を配信（送信）するステップＳ２０２２とを含む。

　ステップＳ２０１４において、送信要求を受信していないと判定された場合、または、ステップＳ２０２２の処理が終了した場合、制御はステップＳ２０００に戻る。

　このように、車載装置は、自車両が走行予定エリアに進入する前に、サーバ装置に対してリソース消費量実績地図の送信を要求することにより、自車両が走行予定エリアに進入する前にリソース消費量実績地図をサーバ装置から取得できる。

　第２の変形例におけるその他の効果は、上記第１の実施の形態と同様である。

　（第３の変形例）
　第３の変形例に係るシステムにおいては、車載装置がサーバ装置に対して自車両の走行予定エリアを通知する。走行予定エリアは、例えば、ナビゲーションシステム等において自車両の搭乗者によって設定（入力）された目的地に基づいて設定される構成であってもよい。この場合、設定（入力）された目的地までのルートが決定され、決定されたルートに応じて走行予定エリアが導出される。さらに、目的地が入力されない場合に、例えば過去の運転履歴、現在の車両の走行挙動等に基づいて走行予定エリアが設定される構成であってもよい。サーバ装置は、車載装置からの通知を受信すると、送信された走行予定エリアに応じたリソース消費量実績地図を選択して、または作成して、通知を送信した車載装置に対して配信する。車載装置がサーバ装置に対して自車両の走行予定エリアを通知するタイミングは、特に限定されない。一例として、自車両の走行予定エリアを通知するタイミングは、第２の変形例と同様、自車両が走行予定エリアに進入する前の任意のタイミングとすることができる。車載装置およびサーバ装置のその他の構成は、上記第１の実施の形態と同様である。

　［ソフトウェア構成］
　《車載装置》
　第３の変形例に係る車載装置においては、図１２に示されるプログラムに代えて、図１７に示されるプログラムが実行される。図１７のプログラムは、図１２のプログラムにおいて、ステップＳ１１１０をさらに含む。図１７のステップＳ１０００からステップＳ１０４０における処理は、図１２に示される各ステップにおける処理と同じである。以下、異なる部分について説明する。

　図１７を参照して、このプログラムは、リソース消費量実績地図を配信するサーバ装置に対して、自車両の走行予定エリアを通知するステップＳ１１１０を含む。ステップＳ１１１０の処理が終了すると、制御はステップＳ１０００に進む。ステップＳ１０４０において、システム終了の指示「無し」と判定された場合は、制御はステップＳ１１１０に戻る。

　《サーバ装置》
　第３の変形例に係るサーバ装置においては、図１３に示されるプログラムに代えて、図１８および図１９に示されるプログラムが実行される。図１８に示されるプログラムは、図１９に示されるプログラムと並行して実行される。

　図１８を参照して、このプログラムは、リソース消費量実績地図を作成するための走行実績情報（例えば、位置情報、時刻情報、およびリソース消費量（観測結果）等）を各車両（先行車両）から収集するステップＳ２０００と、ステップＳ２０００の後に実行され、収集した情報に基づいて、リソース消費量実績地図を作成または更新するステップＳ２０１０とを含む。ステップＳ２０１０の処理が終了すると、制御はステップＳ２０００に戻る。

　図１９を参照して、このプログラムは、車両から走行予定エリアの通知を受信するまで待機するステップＳ２１００と、ステップＳ２１００において、走行予定エリアの通知を受信したと判定された場合に実行され、作成されたリソース消費量実績地図から通知された走行予定エリアに対応するリソース消費量実績地図を選択する、または通知された走行予定エリアに対応するリソース消費量実績地図を作成するステップＳ２１１０と、ステップＳ２１１０の後に実行され、通知された走行予定エリアに対応するリソース消費量実績地図を車両（通知を送信した車両）に対して送信（配信）するステップＳ２１２０とを含む。ステップＳ２１２０の処理が終了すると、制御はステップＳ２１００に戻る。

　第３の変形例に係るシステムにおいては、車載装置が自車両の走行予定エリアをサーバ装置に通知して、走行予定エリアに応じたリソース消費量実績地図をサーバ装置から取得する。これにより、車載装置は、種々の走行予定エリアについて、自車両の走行に伴うリソース消費量の時間的な変動を予測できる。

　第３の変形例におけるその他の効果は、上記第１の実施の形態と同様である。

　（第４の変形例）
　第４の変形例に係るシステムにおいては、リソース消費量実績地図が作成されてからの経過時間を算出し、経過時間に応じて、車載装置が、リソース消費量実績地図を用いたリソース消費量の推定処理を実行する。すなわち、車載装置が取得したリソース消費量実績地図が古い場合、そのリソース消費量実績地図を用いたリソース消費量の推定処理を実行せず、リソース消費量実績地図が比較的新しい場合に、リソース消費量の推定処理を実行する。

　リソース消費量実績地図には、そのリソース消費量実績地図が生成された日時を示す時刻情報が付加されている。車載装置は、時刻情報が示す日時と現在の日時とを比較し、比較結果に応じて、自車両の走行に伴って時間的に変動するリソース消費量を推定する。例えば、比較の結果、リソース消費量実績地図が生成されてから所定時間（例えば、２時間から６時間の範囲内の時間）より長い時間が経過している場合、車載装置はそのリソース消費量実績地図を用いた推定処理は実行しない。これにより、作成された日時が新しい実績情報を用いてリソース消費量を推定できるので、リソース消費量の推定精度を高めることができる。

　［ソフトウェア構成］
　《車載装置》
　第４の変形例に係る車載装置においては、図１２に示されるプログラムに代えて、図２０に示されるプログラムが実行される。図２０のプログラムは、図１２のプログラムにおいて、ステップＳ１１２０およびステップＳ１１３０をさらに含む。図２０のステップＳ１０００からステップＳ１０４０における処理は、図１２に示される各ステップにおける処理と同じである。以下、異なる部分について説明する。

　図２０を参照して、このプログラムは、ステップＳ１０００において、サーバ装置からリソース消費量実績地図を受信したと判定された場合に実行され、受信したリソース消費量実績地図の作成日時を現在の日時と比較するステップＳ１１２０と、ステップＳ１１２０の後に実行され、リソース消費量実績地図が作成されてからの経過時間が所定時間（例えば、２時間から６時間の範囲内の時間）以内か否かを判定し、判定結果に応じて制御の流れを分岐させるステップＳ１１３０とを含む。ステップＳ１１３０において、リソース消費量実績地図が作成されてからの経過時間が所定時間以内ではない（すなわち、所定時間より長い時間が経過している）と判定された場合は、制御はステップＳ１０００に戻る。ステップＳ１１３０において、リソース消費量実績地図が作成されてからの経過時間が所定時間以内であると判定された場合は、制御はステップＳ１０１０に進む。

　なお、リソース消費量実績地図が生成されてから所定時間より長い時間が経過している場合、車載装置は、そのリソース消費量実績地図を破棄して、サーバ装置に対して新たなリソース消費量実績地図の送信を要求するよう構成してもよい。

　（第２の実施の形態）
　図２１を参照して、本実施の形態に係る車載装置２００Ａは、先行車両から走行実績情報（例えば、位置情報、時刻情報、およびリソース消費量（観測結果）等）を取得し、取得した走行実績情報に基づいて、自車両の走行に伴って時間的に変動するリソース消費量を推定する点において、サーバ装置から取得したリソース消費量実績地図に基づいて、リソース消費量を推定する第１の実施の形態とは異なる。その他の構成は、第１の実施の形態と同様である。

　車両１００Ａの車載装置２００Ａは、走行予定エリアを既に走行した複数台（例えば２から３台）の先行車両と車車間通信により通信し、これら先行車両から走行実績情報を取得する。車載装置２００Ａは、取得した走行実績情報を処理することにより、走行予定エリアの走行区間毎に、どのリアルタイムアプリが実行されたかを判別する。車載装置２００Ａは、その判別結果に基づいて、第１の実施の形態と同様にして、走行予定エリアにおけるリアルタイムアプリのリソース消費量を推定する。車載装置２００Ａはさらに、リソース消費量の推定結果に基づいて、非リアルタイムアプリの実行期間をスケジューリングする。

　図２２を参照して、本実施の形態に係る車載装置２００Ａは、ＧＷ装置２１０（図８参照）に代えて、ＧＷ装置２１０Ａを含む。ＧＷ装置２１０Ａは、情報取得部２２０およびリソース管理部２３０（図８参照）に代えて、それぞれ、情報取得部２２２およびリソース管理部２３０Ａを含む。情報取得部２２２は、車外無線装置３００（図８参照）を介して、自車両の走行予定エリアを走行した先行車両から走行予定エリアにおけるリソース消費量の実績情報である「走行実績情報」を取得する。リソース管理部２３０Ａは、リソース消費量推定部２３２（図８参照）に代えて、リソース消費量推定部２３２Ａを含む。リソース消費量推定部２３２Ａは、先行車両から取得した走行実績情報に基づいて、走行予定エリアにおける各走行区間のリソース消費量を推定する。

　［ソフトウェア構成］
　本実施の形態に係る車載装置２００Ａにおいては、図１２に示されるプログラムに代えて、図２３に示されるプログラムが実行される。図２３のプログラムは、図１２のプログラムにおいて、ステップＳ１０００およびステップＳ１０１０に代えて、ステップＳ１２００およびステップＳ１２１０を含む。図２３のステップＳ１０２０からステップＳ１０４０における処理は、図１２に示される各ステップにおける処理と同じである。以下、異なる部分について説明する。

　図２３を参照して、このプログラムは、複数の先行車両から走行実績情報を受信するまで待機するステップＳ１２００と、ステップＳ１２００において複数の先行車両から走行実績情報を受信したと判定された場合に実行され、以下に説明するステップＳ１２１２を、対象リソースの観測領域毎に全ての対象リソースに対する処理が終了するまで繰返すステップＳ１２１０とを含む。ステップＳ１２１０においては、受信した走行実績情報に基づいて、走行予定エリアにおけるリアルタイムアプリのリソース消費量を推定するステップＳ１２１２を含む。ステップＳ１２１０の処理が終了すると、制御はステップＳ１０２０に進む。

　本実施の形態においては、リソース消費量の推定に、サーバ装置から取得したリソース消費量実績地図に代えて、先行車両から取得した走行実績情報を用いる。これによっても、車載装置２００Ａは、自車両の走行に伴って時間的に変動するリソース消費量を容易に推定できる。そのため、車外との通信に起因する高負荷時における応答性の低下を容易に抑制できる。

　その他の効果は、上記第１の実施の形態と同様である。

　（第３の実施の形態）
　本実施の形態に係るシステムは、サーバ装置において、車両におけるリソースに空きがある期間を抽出し、抽出した期間を、非リアルタイムアプリの実行を推奨する実行推奨期間として車両に通知する点において、第１の実施の形態とは異なる。すなわち、本実施の形態においては、非リアルタイムアプリの実行期間を割り当てる期間の抽出処理までをサーバ装置において実行する。

　図２４を参照して、本実施の形態に係るサーバ装置５００Ａは、制御部５２０（図１１参照）に代えて、制御部５２０Ａを含む。制御部５２０Ａは、配信部５６６（図１１参照）に代えて、実行期間抽出部５６８および通知部５７０を機能部として含む。サーバ装置５００Ａは、車載装置から送信された、走行予定エリア、およびリソース管理対象に関する情報を受信している。実績地図作成部５６４は、走行予定エリアに対応したリソース消費量実績地図を作成し、実績地図記憶部５３４に格納する。実行期間抽出部５６８は、走行予定エリアの走行期間において、非リアルタイムアプリの実行を推奨する実行推奨期間をリソース消費量実績地図に基づいて抽出する。具体的には、実行期間抽出部５６８は、リソース管理対象に関する情報とリソース消費量実績地図とに基づいて、走行予定エリアにおけるリアルタイムアプリのリソース消費量を推定する。実行期間抽出部５６８はさらに、リソース消費量の推定結果に基づいて、非リアルタイムアプリの実行が可能な程度にリソースに空きがある期間を実行推奨期間として抽出する。通知部５７０は、実行期間抽出部５６８が抽出した、非リアルタイムアプリの実行推奨期間を、走行予定エリアに関する情報等を送信した車載装置に対して通知する。

　図２５を参照して、本実施の形態に係る車載装置２００Ｂは、ＧＷ装置２１０（図８参照）に代えて、ＧＷ装置２１０Ｂを含む。ＧＷ装置２１０Ｂは、情報取得部２２０（図８参照）が省略されており、リソース管理部２３０（図８参照）に代えて、リソース管理部２３０Ｂを含む。リソース管理部２３０Ｂは、実行推奨期間受信部２３６、およびリソース制御部２３８を含む。実行推奨期間受信部２３６は、サーバ装置５００Ａ（図２４参照）から通知される実行推奨期間を受信する。リソース制御部２３８は、非リアルタイムアプリの実行期間を実行推奨期間に割り当てる。

　サーバ装置５００Ａおよび車載装置２００Ｂのハードウェア構成は、上記第１の実施の形態と同様である。

　［ソフトウェア構成］
　《サーバ装置５００Ａ》
　本実施の形態に係るサーバ装置５００Ａにおいては、図１３に示されるプログラムに代えて、図１８および図２６に示されるプログラムが実行される。図２６に示されるプログラムは、図１８に示されるプログラムと並行して実行される。図１８に示されるプログラムについては、説明を省略する。

　図２６を参照して、このプログラムは、車載装置２００Ｂから走行予定エリアおよびリソース管理対象に関する情報を受信するまで待機するステップＳ２２００と、ステップＳ２２００において、走行予定エリアおよびリソース管理対象に関する情報を受信したと判定された場合に実行され、受信した走行予定エリアに対応したリソース消費量実績地図を実績地図記憶部５３４に格納されている実績地図の中から選択する、または走行予定エリアに対応するリソース消費量実績地図を作成するステップＳ２２１０と、ステップＳ２２１０の後に実行され、以下に説明するステップＳ２２２２を、リソース管理対象に関する情報に基づいて、対象リソースの観測領域毎に全ての対象リソースに対する処理が終了するまで繰返すステップＳ２２２０とを含む。ステップＳ２２２０は、リソース消費量実績地図に基づいて、走行予定エリアにおけるリアルタイムアプリのリソース消費量を対象リソースの観測領域毎に推定するステップＳ２２２２を含む。

　このプログラムはさらに、ステップＳ２２２０の後に実行され、リソース消費量の推定結果に基づいて、車載装置２００Ｂにて実行される非リアルタイムアプリの実行可能な期間を実行推奨期間として抽出するステップＳ２２３０と、ステップＳ２２３０の後に実行され、抽出した実行推奨期間を、走行予定エリアに関する情報を送信した車載装置２００Ｂに対して通知し、制御をステップＳ２２００に戻すステップＳ２２４０とを含む。

　《車載装置２００Ｂ》
　本実施の形態に係る車載装置２００Ｂにおいては、図１２に示されるプログラムに代えて、図２７に示されるプログラムが実行される。

　図２７を参照して、このプログラムは、自車両の走行予定エリアおよびリソース管理対象に関する情報をサーバ装置５００Ａ（図２４参照）に対して通知するステップＳ１３００と、ステップＳ１３００の後に実行され、サーバ装置５００Ａから送信される実行推奨期間を受信するまで待機するステップＳ１３１０と、ステップＳ１３１０において、実行推奨期間を受信したと判定された場合に実行され、受信した実行推奨期間に基づいて、非リアルタイムアプリの実行期間をスケジューリングするステップＳ１３２０と、ステップＳ１３２０の後に実行され、ステップＳ１３２０のスケジューリング処理にて設定した実行期間に非リアルタイムアプリを実行するステップＳ１３３０と、ステップＳ１３３０の後に実行され、システム終了の指示がされたか否かを判定し、判定結果に応じて制御の流れを分岐させるステップＳ１３４０とを含む。ステップＳ１３４０において、システム終了の指示「無し」と判定された場合は、制御はステップＳ１３００に戻る。ステップＳ１３４０において、システム終了の指示「有り」と判定された場合は、このプログラムは終了する。

　ステップＳ１３００において、サーバ装置５００Ａに対して、走行予定エリアおよびリソース管理対象に関する情報を通知するタイミングは、特に限定されない。一例として、これらの情報をサーバ装置５００Ａに通知するタイミングは、自車両が走行予定エリアに進入する前の任意のタイミングとすることができる。

　サーバ装置５００Ａは、第１の実施の形態と同様、複数の先行車両から走行実績情報を収集してリソース消費量実績地図を作成する。サーバ装置５００Ａは、作成したリソース消費量実績地図に基づいて、非リアルタイムアプリの実行を推奨する実行推奨期間を抽出し、抽出した実行推奨期間を車載装置２００Ｂに通知する。車載装置２００Ｂは、非リアルタイムアプリの実行期間を実行推奨期間に割り当てることにより、アプリの実行期間を分散する。これにより、車載装置２００Ｂは、車外との通信に起因する高負荷時において、応答性の低下を容易に抑制できる。このように、サーバ装置５００Ａは、非リアルタイムアプリの実行推奨期間を車載装置２００Ｂに通知することにより、車載装置２００Ｂに対して、車外との通信に起因する高負荷時に応答性の低下を抑制するように支援することができる。

　（変形例）
　上記実施の形態においては、ＧＷ装置にリソース管理部の機能を持たせた例について示したが、本開示はそのような実施の形態には限定されない。ＧＷ装置以外の装置にリソース管理部の機能を持たせてもよい。

　上記実施の形態においては、車載装置がＧＷ装置および車外無線装置を含む例について示したが、本開示はそのような実施の形態には限定されない。車載装置はＧＷ装置および車外無線装置以外の例えばＥＣＵであってもよい。すなわち、ＥＣＵにリソース管理部の機能を持たせてもよい。またリソース管理部の機能を持つ専用のＥＣＵを車載装置として車両に搭載してもよい。さらに、複数の車載装置にリソース管理部を搭載してもよい。

　上記実施の形態においては、非リアルタイムアプリの実行期間をスケジューリングする例について示したが、本開示はそのような実施の形態には限定されない。非リアルタイムアプリの実行期間が既に設定されている場合には、リソース消費量の推定結果に基づいて、非リアルタイムアプリの実行期間を再設定（リスケジューリング）することもできる。

　上記実施の形態においては、サーバ装置は、車両の走行予定エリアまたは特定のエリアのリソース消費量実績地図を作成する例について示したが、本開示はそのような実施の形態には限定されない。例えば、サーバ装置は実装置が管理するエリアのリソース消費量実績地図を作成しておき、作成した広範囲のリソース消費量実績地図から必要とするエリアを抽出して車両に配信するようにしてもよい。

　なお、上述の実施形態の各処理（各機能）は、１または複数のプロセッサを含む処理回路（Ｃｉｒｃｕｉｔｒｙ）により実現されてもよい。上記処理回路は、上記１または複数のプロセッサに加え、１または複数のメモリ、各種アナログ回路、各種デジタル回路が組み合わされた集積回路等により構成されてもよい。上記１または複数のメモリは、上記各処理を上記１または複数のプロセッサに実行させるプログラム（命令）を格納する。上記１または複数のプロセッサは、上記１または複数のメモリから読み出した上記プログラムに従い上記各処理を実行してもよいし、予め上記各処理を実行するように設計された論理回路に従って上記各処理を実行してもよい。上記プロセッサは、ＣＰＵ、ＧＰＵ、ＤＳＰ（Ｄｉｇｉｔａｌ　Ｓｉｇｎａｌ　Ｐｒｏｃｅｓｓｏｒ）、ＦＰＧＡ（Ｆｉｅｌｄ　Ｐｒｏｇｒａｍｍａｂｌｅ　Ｇａｔｅ　Ａｒｒａｙ）、ＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ　Ｓｐｅｃｉｆｉｃ　Ｉｎｔｅｇｒａｔｅｄ　Ｃｉｒｃｕｉｔ）等、コンピュータの制御に適合する種々のプロセッサであってよい。なお物理的に分離した上記複数のプロセッサが互いに協働して上記各処理を実行してもよい。例えば物理的に分離した複数のコンピュータのそれぞれに搭載された上記プロセッサがＬＡＮ（Ｌｏｃａｌ　Ａｒｅａ　Ｎｅｔｗｏｒｋ）、ＷＡＮ（Ｗｉｄｅ　Ａｒｅａ　Ｎｅｔｗｏｒｋ）、インターネット等のネットワークを介して互いに協働して上記各処理を実行してもよい。

　上記で開示された技術を適宜組合せて得られる実施形態についても、本開示の技術的範囲に含まれる。

　今回開示された実施の形態は単に例示であって、本開示が上記した実施の形態のみに限定されるわけではない。本開示の範囲は、発明の詳細な説明の記載を参酌した上で、請求の範囲の各請求項によって示され、そこに記載された文言と均等の意味および範囲内での全ての変更を含む。

　３０　　　システム
　３２　　　走行予定エリア
　５０　　　インフラ装置
　６０　　　動的マップ
　６２　　　実空間
　７０　　　ネットワーク
　１００、１００Ａ　　　車両
　１１０　　　ミリ波レーダ
　１１２　　　車載カメラ
　１１４　　　ＬｉＤＡＲ
　２００、２００Ａ、２００Ｂ　　　車載装置
　２１０、２１０Ａ、２１０Ｂ　　　ＧＷ装置
　２１２、５１０　　　コンピュータ
　２２０、２２２　　　情報取得部
　２３０、２３０Ａ、２３０Ｂ　　　リソース管理部
　２３２、２３２Ａ　　　リソース消費量推定部
　２３４、２３８　　　リソース制御部
　２３６　　　実行推奨期間受信部
　２４０　　　協調仲介部
　２５０、５２０、５２０Ａ　　　制御部
　２５２　　　演算部
　２５４、５２６　　　ＲＯＭ
　２５６、５２８　　　ＲＡＭ
　２６０、５３０　　　記憶装置
　２７０　　　車内ネットワーク通信部
　２８０　　　通信ＩＦ
　２９０、５００　　　バス
　３００　　　車外無線装置
　３１０、３２０、３３０　　　無線ＩＦ
　４００　　　車内ネットワーク
　４１０　　　センサ群
　４２０　　　ＥＣＵ群
　５００、５００Ａ　　　サーバ装置
　５２２　　　ＣＰＵ
　５２４　　　ＧＰＵ
　５３２　　　走行実績情報記憶部
　５３４　　　実績地図記憶部
　５４０　　　ネットワークＩＦ
　５６０　　　通信制御部
　５６２　　　情報収集部
　５６４　　　実績地図作成部
　５６６　　　配信部
　５６８　　　実行期間抽出部
　５７０　　　通知部

Claims

　車両に搭載される車載装置であって、
　外部装置と通信する通信部と、
　前記通信部を介して、自車両以外の車両である他車両が自車両の走行予定エリアを走行したときの、前記他車両のリソース消費量の実績情報を取得する情報取得部と、
　前記情報取得部が取得した前記実績情報に基づいて、前記走行予定エリアを自車両が走行した場合に、自車両の走行に伴って時間的に変動するリソース消費量を推定する推定部と、
　前記推定部の推定結果に応じて、所定のアプリケーションソフトウェアの実行期間を所定の期間に割り当てることにより、リソース消費を制御するリソース制御部とを含む、車載装置。
　前記推定部は、前記走行予定エリアの走行区間に応じて変動するリソース消費量であって、処理の実行にリアルタイム性が要求されるアプリケーションソフトウェアの実行によるリソース消費量を含むリソース消費量を前記走行区間毎に推定し、
　前記リソース制御部は、前記推定部の推定結果に応じて、処理の実行にリアルタイム性が要求されないアプリケーションソフトウェアの実行期間を前記所定の期間に割り当てることにより、リソース消費を制御する、請求項１に記載の車載装置。
　前記外部装置は、複数の他車両から前記リソース消費量の実績情報を収集し、収集した実績情報に基づいて、前記走行予定エリアの走行区間にリソース消費実績が設定されたリソース消費量実績地図を作成するサーバ装置を含み、
　前記情報取得部は、前記通信部を介して、前記サーバ装置から前記リソース消費量実績地図を前記実績情報として取得し、
　前記推定部は、前記リソース消費量実績地図に基づいて、前記走行予定エリアにおける各走行区間のリソース消費量を推定する、請求項１または請求項２に記載の車載装置。
　前記外部装置は、自車両以外の車両である他車両に搭載された車載装置を含み、
　前記情報取得部は、前記通信部を介して、自車両の走行予定エリアを走行した前記他車両の車載装置から前記走行予定エリアにおけるリソース消費量の実績情報を取得し、
　前記推定部は、前記他車両の車載装置から取得した前記リソース消費量の実績情報に基づいて、前記走行予定エリアにおける各走行区間の前記リソース消費量を推定する、請求項１または請求項２に記載の車載装置。
　前記リソース制御部は、リソース使用上限に対する前記推定部が推定したリソース消費量の割合が所定の値以下となる走行区間の走行予定期間に、処理の実行にリアルタイム性が要求されないアプリケーションソフトウェアの実行期間を割り当てる、請求項１または請求項２に記載の車載装置。
　前記所定の値は、前記リアルタイム性が要求されないアプリケーションソフトウェアのリソース消費量に基づいて設定される、請求項５に記載の車載装置。
　前記実績情報は、前記走行予定エリアの走行区間毎に設定され、前記走行予定エリアを走行した前記他車両のリソース消費量の実績値が複数段階に量子化された量子化情報を含む、請求項１または請求項２に記載の車載装置。
　前記情報取得部は、自車両が前記走行予定エリアに進入する前に前記実績情報を取得する、請求項１または請求項２に記載の車載装置。
　前記情報取得部は、自車両が前記走行予定エリアに進入する前に、前記外部装置に対して前記実績情報の送信を要求する、請求項１または請求項２に記載の車載装置。
　前記実績情報には、当該実績情報が生成された日時を示す時刻情報が付加されており、
　前記推定部は、前記時刻情報が示す日時と現在の日時とを比較し、比較結果に応じて、自車両の走行に伴って時間的に変動する前記リソース消費量を推定する、請求項１または請求項２に記載の車載装置。
　車両に搭載される車載装置と通信可能なサーバ装置であって、
　複数の車両からリソース消費量の実績情報を収集する情報収集部と、
　前記車載装置から走行予定エリアに関する情報を受信し、前記情報収集部が収集した実績情報に基づいて、前記走行予定エリアの走行区間にリソース消費実績が設定されたリソース消費量実績地図を作成する実績地図作成部と、
　前記走行予定エリアの走行期間において、処理の実行にリアルタイム性が要求されないアプリケーションソフトウェアの実行を推奨する実行推奨期間を前記リソース消費量実績地図に基づいて抽出する実行期間抽出部と、
　前記実行期間抽出部が抽出した前記実行推奨期間を、前記走行予定エリアに関する情報を送信した前記車載装置に対して通知する通知部とを含む、サーバ装置。
　車両に搭載される車載装置におけるリソース制御方法であって、
　前記車載装置が、外部装置と通信する通信部を介して、自車両以外の車両である他車両が自車両の走行予定エリアを走行したときの、前記他車両のリソース消費量の実績情報を取得するステップと、
　前記車載装置が、前記取得するステップにおいて取得した前記実績情報に基づいて、前記走行予定エリアを自車両が走行した場合に、自車両の走行に伴って時間的に変動するリソース消費量を推定するステップと、
　前記車載装置が、前記推定するステップにおける推定結果に応じて、所定のアプリケーションソフトウェアの実行期間を所定の期間に割り当てることにより、リソース消費を制御するステップとを含む、リソース制御方法。
　車両に搭載される車載装置と通信可能なサーバ装置において実行され、前記車両におけるリソース消費の制御を支援するリソース制御支援方法であって、
　サーバ装置が、複数の車両からリソース消費量の実績情報を収集するステップと、
　サーバ装置が、前記車載装置から走行予定エリアに関する情報を受信し、前記収集するステップにおいて収集した実績情報に基づいて、前記走行予定エリアの走行区間にリソース消費実績が設定されたリソース消費量実績地図を作成するステップと、
　サーバ装置が、前記走行予定エリアの走行期間において、処理の実行にリアルタイム性が要求されないアプリケーションソフトウェアの実行を推奨する実行推奨期間を前記リソース消費量実績地図に基づいて抽出するステップと、
　サーバ装置が、前記抽出するステップにおいて抽出した前記実行推奨期間を、前記走行予定エリアに関する情報を送信した前記車載装置に対して通知するステップとを含む、リソース制御支援方法。
　車両に搭載されるコンピュータを、
　外部装置と通信する通信部、
　前記通信部を介して、自車両以外の車両である他車両が自車両の走行予定エリアを走行したときの、前記他車両のリソース消費量の実績情報を取得する情報取得部、
　前記情報取得部が取得した前記実績情報に基づいて、前記走行予定エリアを自車両が走行した場合に、自車両の走行に伴って時間的に変動するリソース消費量を推定する推定部、および、
　前記推定部の推定結果に応じて、所定のアプリケーションソフトウェアの実行期間を所定の期間に割り当てることにより、リソース消費を制御するリソース制御部として機能させる、コンピュータプログラム。
　コンピュータを、
　複数の車両からリソース消費量の実績情報を収集する情報収集部、
　車載装置から走行予定エリアに関する情報を受信し、前記情報収集部が収集した実績情報に基づいて、前記走行予定エリアの走行区間にリソース消費実績が設定されたリソース消費量実績地図を作成する実績地図作成部、
　前記走行予定エリアの走行期間において、処理の実行にリアルタイム性が要求されないアプリケーションソフトウェアの実行を推奨する実行推奨期間を前記リソース消費量実績地図に基づいて抽出する実行期間抽出部、および、
　前記実行期間抽出部が抽出した前記実行推奨期間を、前記走行予定エリアに関する情報を送信した前記車載装置に対して通知する通知部として機能させる、コンピュータプログラム。