JP7747202B2 - リソース割当方法および装置、ならびにコンピュータプログラム - Google Patents

Description

この開示は、リソース割当方法および装置、ならびにコンピュータプログラムに関する。この出願は2022年6月9日出願の日本出願第2022-093583号に基づく優先権を主張し、前記日本出願に記載された全ての記載内容を援用するものである。

運転支援機能を有する車載装置の場合、その利用できる演算リソースに変更が生ずる場合がある。例えば車両の機器の一部が故障すると、その機器が担っていた機能が車載装置から利用できなくなる。そうした場合に、失われた機能に他の演算リソースを割り当てる必要が生じる。後掲の特許文献１には、そのような場合に演算リソースの再割当を行う技術が開示されている。

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

この開示の第１の局面に係るリソース割当方法は、サーバとの通信により運転支援機能を提供する車載装置におけるリソース割当方法であって、車載装置は、車載装置を搭載した車両の走行エリアを管轄するサービス提供装置のリソースと車載装置を搭載した車両である自車両のリソースとを切り替えて車載装置の各機能に割り当てる切替型車載装置であり、リソース割当方法は、コンピュータが、自車両の走行エリアを管轄するサービス提供装置であるサーバのリソースと、自車両のリソースとを車載装置の各機能に割り当てる割当処理を実行するステップと、コンピュータが、走行エリア内に存在している、サーバとの連携を行う車両の数の変化を検出または予測したことに応答して、割当処理を再実行するステップとを含む。

この開示の第２の局面に係るリソース割当装置は、サーバとの通信により運転支援機能を提供する車載装置におけるリソース割当装置であって、車載装置は、車載装置を搭載した車両の走行エリアを管轄するサーバのリソースと車載装置を搭載した車両である自車両のリソースとを切り替えて車載装置の各機能に割り当てる切替型車載装置であり、リソース割当装置は、自車両の走行エリアを管轄するサーバのリソースと、自車両のリソースとを車載装置の各機能に割り当てる割当処理を実行する割当実行部と、走行エリア内に存在している、サーバとの連携を行う車両の数の変化を検出または予測したことに応答して、割当処理を再実行する割当再実行部とを含む。

この開示の第３の局面に係るコンピュータプログラムは、コンピュータを、サーバとの通信により運転支援機能を提供する車載装置においてリソースの割当を行うように機能させるコンピュータプログラムであって、車載装置は、車載装置を搭載した車両の走行エリアを管轄するサーバのリソースと車載装置を搭載した車両である自車両のリソースとを切り替えて車載装置の各機能に割り当てる切替型車載装置であり、コンピュータプログラムは、コンピュータを、自車両の走行エリアを管轄するサーバのリソースと、自車両のリソースとを車載装置の各機能に割り当てる割当処理を実行する割当実行部と、走行エリア内に存在している、サーバとの連携を行う車両の数の変化を検出または予測したことに応答して、割当処理を再実行する割当再実行部として機能させる。
この発明の上記および他の目的、特徴、局面および利点は、添付の図面と関連して理解されるこの発明に関する次の詳細な説明から明らかとなるであろう。

図１は、車載エッジサーバ（以下、単に「車載エッジ」という。）の技術的発展段階を示す図である。 図２は、この開示の第１実施形態に係る協調システムに参加する車両の車両システムの概略構成を示すブロック図である。 図３は、第１実施形態に係る協調システムの１例を示す図である。 図４は、図２に示す車両システムの車載エッジを実現するコンピュータのハードウェアブロック図である。 図５は、図４に示す車載エッジの機能的構成を示すブロック図である。 図６は、サーバ構成の種類とその特徴とを表形式で示す図である。 図７は、車両の周辺に存在する車両の種類、車両移動の変化状況、およびサーバリソース状況の組み合わせに伴う、車載エッジとサーバとの連携の切替パターンを表形式で示す図である。 図８は、車載エッジが実行するプログラムの概略構成を示すフローチャートである。 図９は、リソースを自車両とサーバとの間で切替可能な切替型の車載エッジにおけるリソースの再割当を行うプログラムの制御構造を示すフローチャートである。 図１０は、図９に示すフローチャートにおいて、切替型の周辺車両があるときに実行されるプログラムの制御構造の前半を示すフローチャートである。 図１１は、図９に示すフローチャートにおいて、切替型の周辺車両があるときに実行されるプログラムの制御構造の後半を示すフローチャートである。 図１２は、図９に示すフローチャートにおいて、切替型の周辺車両がないときに実行されるプログラムの制御構造の前半を示すフローチャートである。 図１３は、図９に示すフローチャートにおいて、切替型の周辺車両がないときに実行されるプログラムの制御構造の後半を示すフローチャートである。 図１４は、切替先のサーバの構成に対する、切替型の車両におけるリアルタイムアプリおよび非リアルタイムアプリのリソース割当を表形式で示す図である。 図１５は、切替型の車載装置において、ある機能のためのリソースを自車両からサーバに切り替えるためのプログラムの制御構造を示すフローチャートである。 図１６は、サーバリソース状況と、周辺車両とのリソースの調整のためのリアルタイムアプリと非リアルタイムアプリとに対するリソース割当を表形式で示す図である。 図１７は、切替型周辺車両とのリソース調整を行うためのプログラムの制御構造を示すフローチャートである。 図１８は、エッジサーバ（以下「エッジ」という。）を使用したリソースの切替を行うプログラムの制御構造を示すフローチャートである。 図１９は、リアルタイムアプリに関する、切替型周辺車両との優先度処理のためのプログラムの制御構造を示すフローチャートである。 図２０は、非リアルタイムアプリに関する、切替型周辺車両との優先度処理のためのプログラムの制御構造を示すフローチャートである。 図２１は、エッジを使用しないリソースの切替を行うプログラムの制御構造を示すフローチャートである。

［本開示が解決しようとする課題］
特許文献１に開示の技術によれば、車載装置が利用できなくなった演算リソースとは別の種類の演算リソースにも、その機能を割り当てることができるという効果が得られる。

しかし、今後は運転支援機能を有する車載装置の普及が加速することが予測される。一方、車載装置に要求される機能そのものも多様化すると考えられる。たとえば、車両のハードウェアの制限により、車載装置が利用できる演算リソースによっては実現できないような機能が出現することも考えられる。そうした問題には特許文献１に開示の技術は十分に対応できない。

したがってこの開示は、様々な機能を柔軟に提供できるようなリソース割当方法および装置、ならびにコンピュータプログラムを提供することを目的とする。

［本開示の効果］
以上のようにこの開示によると、様々な機能を柔軟に提供できるようなリソース割当方法および装置、ならびにコンピュータプログラムが提供できる。

［本開示の実施形態の説明］
以下の説明および図面においては、同一の部品には同一の参照番号を付してある。したがって、それらについての詳細な説明は繰返さない。なお、以下の１または複数の任意の特徴を組み合わせてもよい。

（１） この開示の第１の局面に係るリソース割当方法は、サーバとの通信により運転支援機能を提供する車載装置におけるリソース割当方法であって、車載装置は、車載装置を搭載した車両の走行エリアを管轄するサービス提供装置のリソースと車載装置を搭載した車両である自車両のリソースとを切り替えて車載装置の各機能に割り当てる切替型車載装置であり、リソース割当方法は、コンピュータが、自車両の走行エリアを管轄するサービス提供装置であるサーバのリソースと、自車両のリソースとを車載装置の各機能に割り当てる割当処理を実行するステップと、コンピュータが、走行エリア内に存在している、サーバとの連携を行う車両の数の変化を検出または予測したことに応答して、割当処理を再実行するステップとを含む。

この構成により、走行エリア内に存在している、サーバとの連携を行う車両の数の変化に応じて、各機能を実現するためのリソースをサーバと車両との間で柔軟に割り当てることができる。その結果、車両のための様々な機能を柔軟に提供できる。

（２） 上記（１）において、再実行するステップは、コンピュータが、走行エリアと走行エリアに隣接する隣接エリアとを含む周辺エリア内に存在する各車両が、サービス提供装置との連携を行なわない単独型車両、リソースの固定的な割当を使用してサービス提供装置と連携する連携型車両、および切替型車載装置を搭載する切替型車両のいずれであるかを判別するステップと、コンピュータが、周辺エリア内に単独型車両以外の車両が存在するか否かを判定する第１判定ステップと、コンピュータが、第１判定ステップにおいて周辺エリア内に単独型車両以外の車両が存在すると判定されたことに応答して、サーバにおいて利用可能なリソースに応じて、自車両のリソースとサーバのリソースとを車載装置の各機能に再割当する処理を実行するステップとを含んでもよい。

この構成により、周辺エリア内に存在している単独型車両の数に関係なく、サーバとの連携を行う車両の数に応じて、各機能を実現するためのリソースをサーバと車両との間で柔軟に割り当てることができる。その結果、車両のための様々な機能を柔軟に提供できる。

（３） 上記（２）において、再割当する処理を実行するステップは、コンピュータが、周辺エリア内に自車両以外に切替型車両が存在しているか否かを判定する第２判定ステップと、コンピュータが、第２判定ステップにおける判定が肯定であることに応答して、周辺エリア内に存在する切替型車両とのサーバのリソースに関する調整結果と、サーバにおいて利用可能なリソースの状況とに基づき、サーバのリソースと、自車両のリソースとを車載装置の各機能に再割当する処理を実行する第１再割当実行ステップと、コンピュータが、第２判定ステップにおける判定が否定であることに応答して、サーバにおいて利用可能なリソースの状況に基づき、サーバのリソースと、自車両のリソースとを車載装置の各機能に再割当する処理を実行する第２再割当実行ステップとを含んでもよい。

この構成により、走行エリア内に存在している単独型車両の数および連携型車両の数に関係なく、周辺の切替型車両の数に応じて、各機能を実現するためのリソースをサーバと自車両との間で柔軟に割り当てることができる。その結果、車両のための様々な機能を柔軟に提供できる。

（４） 上記（３）において、第１再割当実行ステップは、コンピュータが、第２判定ステップにおける判定が肯定であることに応答して、走行エリア内に存在する連携型車両または切替型車両の増加を検出または予測する第１検出ステップと、コンピュータが、第１検出ステップにおいて走行エリア内に存在する連携型車両または切替型車両の増加が検出または予測されたことに応答して、サーバのリソースが不足するか否かを判定する第３判定ステップと、コンピュータが、第３判定ステップにおける判定結果が肯定であることに応答して、周辺エリア内に存在する切替型車両とのサーバのリソースに関する調整を実行し、調整の結果に基づいて、車載装置の機能に割り当てられていたサーバのリソースの少なくとも一部を自車両のリソースに切り替えるステップとを含んでもよい。

この構成により、走行エリア内に存在している単独型車両の数に関係なく、走行エリア内の切替型車両および連携型車両の増加を検出したことまたはそれを予測したことに応じて、減少が予測されるサーバのリソースを車両間で調整し、一部の機能に自車両のリソースを割り当てることができる。その結果、他の切替型車両との協働により、各機能を実現するためのリソースをサーバと自車両との間で柔軟に割り当てることができる。その結果、車両のための様々な機能を柔軟に提供できる。

（５） 上記（４）において、第１再割当実行ステップは、さらに、コンピュータが、第２判定ステップにおける判定が肯定であることに応答して、走行エリア内に存在する連携型車両または切替型車両の減少を検出または予測する第２検出ステップと、コンピュータが、第２検出ステップにおいて走行エリア内に存在する連携型車両または切替型車両の減少が検出または予測されたことに応答して、サーバのリソースに余裕が生じるか否かを判定する第４判定ステップと、コンピュータが、第４判定ステップにおける判定結果が肯定であることに応答して、周辺エリア内に存在する切替型車両とのサーバのリソースに関する調整を実行し、調整の結果にもとづいて、車載装置の機能に割り当てられていた自車両のリソースの少なくとも一部をサーバのリソースに切り替えるステップと含んでもよい。

この構成により、走行エリア内に存在している単独型車両の数に関係なく、走行エリア内の切替型車両および連携型車両の数の減少が検出されたことまたはその予測がされたことに応じて、サーバで余裕が生じたリソースを車両間で調整して配分することで、自車両のリソースが割り当てられていた機能の一部にサーバのリソースを新たに割り当てることができる。その結果、各機能を実現するためのリソースをサーバと自車両との間で柔軟に割り当て、自車両の負担を軽減できる。その結果、車両のための様々な機能を柔軟に提供できる。

（６） 上記（３）において、第１再割当実行ステップは、コンピュータが、第２判定ステップにおける判定が肯定であることに応答して、走行エリア内に存在する連携型車両または切替型車両の減少を検出または予測する第２検出ステップと、コンピュータが、第２検出ステップにおいて走行エリア内に存在する連携型車両または切替型車両の減少が検出または予測されたことに応答して、サーバのリソースに余裕が生じるか否かを判定する第３判定ステップと、コンピュータが、第３判定ステップにおける判定結果が肯定であることに応答して、車載装置の機能に割り当てられていた自車両のリソースの少なくとも一部をサーバのリソースに切り替えるステップとを含んでもよい。

この構成により、走行エリア内に存在している単独型車両の数に関係なく、走行エリア内の切替型車両および連携型車両の数の減少が検出されたことまたはその予測がされたことに応じて、サーバで余裕が生じたリソースを車両間で調整して配分することで、自車両のリソースが割り当てられていた機能の一部にサーバのリソースを新たに割り当てることができる。その結果、各機能を実現するためのリソースをサーバと自車両との間で柔軟に割り当て、自車両の負担を軽減できる。その結果、車両のための様々な機能を柔軟に提供できる。

（７） 上記（３）から（６）のいずれか１つにおいて、第２再割当実行ステップは、コンピュータが、第２判定ステップにおける判定が否定であることに応答して、走行エリア内に存在する連携型車両の増加を検出または予測するエリア内増加検出ステップと、コンピュータが、エリア内増加検出ステップにおいて走行エリア内に存在する連携型車両の増加が検出または予測されたことに応答して、サーバのリソースが不足するか否かを判定する第１サーバリソース判定ステップと、コンピュータが、第１サーバリソース判定ステップにおける判定結果が肯定であることに応答して、車載装置の機能に割り当てられていたサーバのリソースの少なくとも一部を自車両のリソースに切り替えるステップとを含む。

この構成により、走行エリア内に存在している単独型車両の数に関係なく、走行エリア内の連携型車両の数の増加が検出されたことまたはその予測がされたことに応じて、減少が予測されるサーバのリソースを車両間で調整して配分することで、サーバのリソースが割り当てられていた機能の一部に自車両のリソースを新たに割り当てることができる。その結果、走行エリア内の連携型車両が増加しても、各機能を実現するためのリソースをサーバと自車両との間で柔軟に割り当て、サーバの負担を軽減できる。その結果、車両のための様々な機能を柔軟に提供できる。

（８） 上記（７）において、第２再割当実行ステップは、さらに、コンピュータが、第１サーバリソース判定ステップにおける判定が否定であることに応答して、走行エリア内に存在する連携型車両の減少を検出または予測するエリア内減少検出ステップと、コンピュータが、エリア内減少検出ステップにおいて走行エリア内に存在する連携型車両の減少が検出または予測されたことに応答して、サーバのリソースに余裕が生じるか否かを判定する第２サーバリソース判定ステップと、コンピュータが、第２サーバリソース判定ステップにおける判定結果が肯定であることに応答して、車載装置の機能に割り当てられていた自車両のリソースの少なくとも一部をサーバのリソースに切り替えるステップとを含んでもよい。

この構成により、サーバのリソースに余裕が生じる場合には、機能の実行に割り当てられていた自車両のリソースの一部を解放し、サーバのリソースを割り当てることができる。その結果、自車両の負担を軽減し、車両のための様々な機能を柔軟に提供できる。

（９） 上記（３）から（６）のいずれか１つにおいて、第２再割当実行ステップは、コンピュータが、第２判定ステップにおける判定が否定であることに応答して、走行エリア内に存在する連携型車両の減少を検出または予測するエリア内減少検出ステップと、コンピュータが、エリア内減少検出ステップにおいて走行エリア内に存在する連携型車両の数の減少が検出または予測されたことに応答して、サーバのリソースに余裕が生じるか否かを判定する第１サーバリソース判定ステップと、コンピュータが、第１サーバリソース判定ステップにおける判定結果が肯定であることに応答して、車載装置の機能に割り当てられていた自車両のリソースの少なくとも一部をサーバのリソースに切り替えるステップとを含んでもよい。

この構成により、サーバのリソースに余裕が生じる場合には、機能の実行に割り当てられていた自車両のリソースの一部を解放し、サーバのリソースを割り当てることができる。その結果、自車両の負担を軽減し、車両のための様々な機能を柔軟に提供できる。

（１０） 上記（５）、（６）、（８）および（９）のいずれか１つにおいて、走行エリアのサーバは、少なくとも第１サーバを含み、車載装置の機能は、第１機能と、第１機能よりも速いレスポンスを必要とする第２機能とを含み、サーバのリソースに切り替えるステップは、走行エリアのサーバが、第１サーバよりレスポンスの速い第２サーバをさらに含むか否かを判定するサーバ構成判定ステップと、サーバ構成判定ステップにおいて、サーバが第２サーバを含まないと判定されたことに応答して、第２機能に自車両のリソースを割り当て、第１機能に第１サーバのリソースを割り当てるステップとを含んでもよい。

この構成により、速いレスポンスを必要とする機能に、自車両ではなく第２サーバのリソースを割り当てることができる。そのため、自車両の負荷を軽減でき、車両のための様々な機能を柔軟に提供できる。

（１１） 上記（５）、（６）、（８）および（９）のいずれか１つにおいて、サーバのリソースに切り替えるステップは、さらに、サーバ構成判定ステップにおいて、サーバが第２サーバを含むと判定されたことに応答して、第１機能に第１サーバのリソースを割り当て、第２機能に第２サーバのリソースを割り当てるステップを含んでもよい。

この構成により、速いレスポンスを必要とする機能に、自車両ではなく第２サーバのリソースを割り当て、速いレスポンスが不要な機能には第１サーバのリソースを割り当てることができる。そのため、自車両の負荷を軽減でき、車両のための様々な機能を柔軟に提供できる。

（１２） 上記（５）、（６）、（８）および（９）のいずれか１つにおいて、走行エリアのサーバは、少なくとも第１サーバを含み、車載装置の機能は、第１機能と、第１機能よりも速いレスポンスを必要とする第２機能とを含み、サーバのリソースに切り替えるステップは、走行エリアのサーバが、第１サーバよりレスポンスの遅い第２サーバをさらに含むか否かを判定するサーバ構成判定ステップと、サーバ構成判定ステップにおいて、サーバが第２サーバを含まないと判定されたことに応答して、第１機能および第２機能に第１サーバのリソースを割り当てるステップとを含んでもよい。

この構成により、速いレスポンスを必要とする機能には自車両のリソースを割り当て、速いレスポンスが不要な機能には第１のサーバのリソースを割り当てることができる。速いレスポンスが不要な機能に第１のサーバのリソースを割り当てるため、自車のリソースを速いレスポンスが必要な機能に有効に利用できる。その結果、自車両の負荷を軽減しながら、車両のための様々な機能を柔軟に提供できる。

（１３） 上記（１２）においてサーバのリソースに切り替えるステップは、さらに、サーバ構成判定ステップにおいて、サーバが第２サーバを含むと判定されたことに応答して、第１機能に第２サーバのリソースを割り当て、第２機能に第１サーバのリソースを割り当てるステップを含んでもよい。

この構成により、速いレスポンスを必要とする機能には第２サーバのリソースを割り当て、速いレスポンスが不要な機能には第１のサーバのリソースを割り当てることができる。自車のリソースをさらにその他の機能に割り当てることができ、自車両の負荷を軽減しながら、車両のための様々な機能を柔軟に提供できる。

（１４） 上記（５）または（６）において、走行エリアのサーバは、第１サーバと、第１サーバよりもレスポンスの速い第２サーバとを含み、車載装置の機能は、第１機能と、第１機能よりも速いレスポンスを必要とする第２機能とを含んでもよく、サーバのリソースに切り替えるステップは、第２機能に第２サーバが許す限り多く第２サーバのリソースを割り当てるステップと、第１機能に第１サーバおよび第２サーバが許す限り多く第１サーバのリソースおよび第２サーバのリソースを割り当てるステップと、第２機能の中で第２サーバのリソースが割り当てられない機能、および第１機能の中で第１サーバのリソースも第２サーバのリソースも割り当てられない機能に自車両のリソースを割り当てるステップとを含んでもよい。

この構成により、速いレスポンスを必要とする機能には、できる限り多く第２サーバのリソースを割り当てることができる。また速いレスポンスが不要な機能には、できるかぎり多く第１サーバおよび第２サーバにリソースを割り当てることができる。したがって、自車両の負荷を軽減し、他の機能に自車両のリソースが割り当てられる。その結果、車両のための様々な機能を柔軟に提供できる。

（１５） 上記（１４）において、第２機能に第２サーバが許す限り多く第２サーバのリソースを割り当てるステップは、第２機能の全てに第２サーバのリソースが割り当てられるか否かを判定する割当判定ステップと、割当判定ステップにおいて第２機能の全てに第２サーバのリソースが割り当てられると判定されたことに応答して、第２機能の全てに第２サーバのリソースを割り当てるステップと、割当判定ステップにおいて第２機能の少なくとも一部に第２サーバのリソースが割り当てられないと判定されたことに応答して、走行エリア内の他の切替型車両との間で第２サーバのリソースの割当の調整を実行し、調整の結果にしたがって第２機能の一部に第２サーバのリソースを可能な限り多く割り当てるステップと、調整の結果、第２機能の中で、第２サーバのリソースが割り当てられない機能に自車両のリソースを割り当てるステップとを含んでもよい。

この構成の結果、速いレスポンスが必要な第２機能の全てに第２サーバのリソースを割り当てることができれば、他の車両との調整の必要なく、第２機能の全てに第２サーバのリソースを割り当てられる。自車両のリソースに余裕ができ、他の多様な機能を実現できる。また第２機能の一部に第２サーバのリソースを割り当てることができない場合にも、他の切替型車両との調整により、走行エリア内の車両にとって第２サーバのリソースを有効に利用できるようにした上で、自車両の機能に第２サーバのリソースをできる限り多く割り当てることができる。その結果、第２サーバのリソースを自車両だけではなく走行エリア内の他の車両にとっても有効に利用し、様々な機能を提供できる。

（１６） 上記（１４）または（１５）において、第１機能に第１サーバおよび第２サーバが許す限り多く第１サーバのリソースおよび第２サーバのリソースを割り当てるステップは、第１機能の全てに第１サーバのリソースが割り当てられるか否かを判定する追加判定ステップと、追加判定ステップにおいて第１機能の全てに第１サーバのリソースが割り当てられると判定されたことに応答して、第１機能の全てに第１サーバのリソースを割り当てるステップと、追加判定ステップにおいて第１機能の少なくとも一部に第１サーバのリソースが割り当てられないと判定されたことに応答して、走行エリア内の他の連携型車両および切替型車両との間で第１サーバのリソースの割当の調整を実行し、調整の結果にしたがって第１機能の一部に第１サーバのリソースを可能な限り割り当てるステップと、調整の結果、第１機能の中で、第１サーバのリソースが割り当てられない機能に自車両のリソースを割り当てるステップとを含んでもよい。

この構成の結果、第１機能の全てに第１サーバのリソースを割り当てることができれば、他の車両との調整の必要なく、第１機能の全てに第１サーバのリソースを割り当てられる。自車両のリソースに余裕ができ、他の多様な機能を実現できる。また第１機能の一部に第１サーバのリソースを割り当てることができない場合にも、他の切替型車両との調整により、走行エリア内の車両にとって第１サーバのリソースを有効に利用できる。さらに、自車両は、自車両の第１機能に第１サーバのリソースをできる限り多く割り当てた上で、残りの第１機能に自車両のリソースを割り当てることができる。その結果、第１サーバのリソースを自車両だけではなく走行エリア内の他の車両にとっても有効に利用し、第１機能を含めた様々な機能を提供できる。

（１７） この開示の第２の局面に係るリソース割当装置は、サーバとの通信により運転支援機能を提供する車載装置におけるリソース割当装置であって、車載装置は、車載装置を搭載した車両の走行エリアを管轄するサーバのリソースと車載装置を搭載した車両である自車両のリソースとを切り替えて車載装置の各機能に割り当てる切替型車載装置であり、リソース割当装置は、自車両の走行エリアを管轄するサーバのリソースと、自車両のリソースとを車載装置の各機能に割り当てる割当処理を実行する割当実行部と、走行エリア内に存在している、サーバとの連携を行う車両の数の変化を検出または予測したことに応答して、割当処理を再実行する割当再実行部とを含む。

この構成により、走行エリア内に存在している、サーバとの連携を行う車両の数の変化に応じて、各機能を実現するためのリソースをサーバと車両との間で柔軟に割り当てることができる。その結果、車両のための様々な機能を柔軟に提供できる。

（１８） この開示の第３の局面に係るコンピュータプログラムは、コンピュータを、サーバとの通信により運転支援機能を提供する車載装置においてリソースの割当を行うように機能させるコンピュータプログラムであって、車載装置は、車載装置を搭載した車両の走行エリアを管轄するサーバのリソースと車載装置を搭載した車両である自車両のリソースとを切り替えて車載装置の各機能に割り当てる切替型車載装置であり、コンピュータプログラムは、コンピュータを、自車両の走行エリアを管轄するサーバのリソースと、自車両のリソースとを車載装置の各機能に割り当てる割当処理を実行する割当実行部と、走行エリア内に存在している、サーバとの連携を行う車両の数の変化を検出または予測したことに応答して、割当処理を再実行する割当再実行部として機能させる。

この構成により、走行エリア内に存在している、サーバとの連携を行う車両の数の変化に応じて、各機能を実現するためのリソースをサーバと車両との間で柔軟に割り当てることができる。その結果、車両のための様々な機能を柔軟に提供できる。

［本開示の実施形態の詳細］
本開示の実施形態に係るリソース割当方法および装置、ならびにコンピュータプログラムの具体例を、以下に図面を参照しつつ説明する。なお、本開示はこれらの例示に限定されるものではなく、請求の範囲によって示され、請求の範囲と均等の意味および範囲内での全ての変更が含まれることが意図される。

第１ 第１実施形態
１ 開示の背景
運転支援のシステムとして、車両にセンサを搭載し、このセンサデータに対する情報処理を全て車載装置で行うものがある。センサデータが得られた場所でそのデータに対する処理が実行されるので、リアルタイムで行うことが必要な処理をするためにはこのような方式の都合がよい。この明細書においては、このように運転支援のための情報処理を車載装置で実行する機能を車載エッジと呼ぶ。

図１に、車載エッジを搭載した車両システムの技術的発展段階を模式的に示す。図１を参照して、初期の車両システム５０は、他の車両などとは切り離された単独型の車載エッジ６０と、図示しない各種のセンサとを含む。単独型の車載エッジ６０はこれらセンサからのセンサデータを処理するアプリを含む。これらアプリは、車両の安全に不可欠な機能を実現するリアルタイムアプリと、直接には車両の安全に寄与しない非リアルタイムアプリの双方を実行する。このような単独型の車載エッジ６０を搭載した車両を、この明細書においては単独型車両という。

しかしこうした車載エッジ６０においては、例えば広域の情報を運転支援に役立てることができないという問題がある。また車載エッジ６０を搭載した車両のセンサから得た情報を他の車両の運転に利用することができないという問題もある。

続く発展段階の車両システム５２は、上記した単独型の車両システム５０の欠点を補うものであって、図示しないセンサに加え、所定のエリアを管轄するサーバ７２と通信可能な車載エッジ７０を含む。車載エッジ７０は、リアルタイムアプリを実行する。一方、サーバ７２は車載エッジ７０から送信されるセンサデータを使用して非リアルタイムアプリを実行する。サーバ７２は、非リアルタイムアプリの実行結果を車載エッジ７０に送信する。車載エッジ７０はこの情報を運転支援に使用する。

このように、車載エッジ７０は、サーバ７２と連携して運転支援の処理を行う。したがって車載エッジ７０を連携型の車載エッジと呼ぶ。また連携型の車載エッジを搭載した車両を連携型車両という。連携型の車載エッジは、車内の各部と外部との通信を行う車載ゲートウェイ（以下「車載ＧＷ（Ｇａｔｅｗａｙ）」という。）の内部に設けられる。

車両システム５２よりさらに発展した段階の車両システム５４として、サーバ８２および他の車両などと通信することが可能な切替型の車載エッジ８０を搭載したものを考えることができる。車載エッジ８０は、リアルタイムアプリと非リアルタイムアプリとの双方について、車載エッジ８０で実行するか、サーバ８２で実行するかを切り替えることができる。車載エッジ８０はそのために、それらアプリに車載エッジ８０を搭載した車両（自車両という。）のリソースを割り当てるか、サーバ８２のリソースを割り当てるかを制御するためのリソース制御部を含む。このような切替型の車載エッジ８０を搭載した車両を切替型車両という。

このように、車載エッジには技術的な発展段階があるものの、社会で使用されている車載エッジが一律に（同時に）より上位の車載エッジに置き換えられるものではない。単独型、連携型、および切替型の車載エッジを搭載した車両が道路上で混在することが考えられる。こうしたときには、サーバのリソースをめぐり様々な問題が生じ得る。

２ 構成
２Ａ ハードウェア構成
例えば図１に示す車両システム５４の概略構成は以下のようなものである。図２を参照して、車両システム５４は、センサ１００、ＥＣＵ（Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）１０２、自動運転ＥＣＵ１０４、サーバ８２と通信するための無線通信部１０６、および車両システム５４の各部と無線通信部１０６を介したサーバ８２との通信の中継および振り分けを行うための車載ＧＷ１０８とを含む。車載ＧＷ１０８は車載エッジ８０を含む。車載エッジ８０は、センサ１００、ＥＣＵ１０２、自動運転ＥＣＵ１０４および無線通信部１０６に接続されている。車載エッジ８０は、センサ１００からのセンサデータを車載エッジ８０内で処理したり、無線通信部１０６を介してサーバ８２に送信してサーバ８２によるアプリの実行結果を受信したりする。車載エッジ８０は、そうした情報をＥＣＵ１０２および自動運転ＥＣＵ１０４などに与え、運転支援に役立てる。

なお、図２において、センサ１００およびＥＣＵ１０２についてはいずれも１つしか示していない。しかし、実際にはセンサ１００としては異なるセンサがそれぞれ１または複数個存在しており、ＥＣＵ１０２についても異なる機能のＥＣＵがそれぞれ１または複数個存在している。ＥＣＵ１０２は実質的にはコンピュータであり、指定されたプログラムを実行して結果を他のＥＣＵなどに出力するか、またはプログラムを実行することにより車両の各部を制御する機能を持つ。

図１に示す車両システム５０は図２において無線通信部１０６を含まない形式のものである。また車両システム５２は図２と同様のハードウェア構成を持つ。

２Ｂ 機能的構成
以下、この第１実施形態に係る車載エッジ８０を搭載した車両３２０に関連して生じ得る問題について説明する。なお、以下の実施形態では、車両３２０が走行しているエリアを走行エリアという。走行エリアに隣接しているエリアであって、他のサーバが管轄しているエリアを隣接エリアという。走行エリアと隣接エリアをまとめて周辺エリアという。周辺エリア内を走行している車両を周辺車両という。なお、サーバにはクラウドサーバ（以下、単に「クラウド」という。）とエッジサーバ（以下、単に「エッジ」という。）との２種類がある。クラウドはエッジより広いエリアを扱うことが多い。エッジはより狭い領域を扱う。したがってエッジはクラウドよりも高速に各車両の要求を処理できる。

図３を参照して、車両３２０の走行エリアが走行エリア３００であるとする。走行エリア３００を管轄しているサーバをクラウド３０４とする。また走行エリア３００に隣接するエリアの１つを隣接エリア３０２とし、隣接エリア３０２を管轄しているサーバはクラウド３０６およびエッジ３０８の組み合わせからなるものとする。クラウド３０６は隣接エリア３０２の広い領域を管轄し、エッジ３０８は隣接エリア３０２内の狭い領域を管轄している。クラウド３０６は、隣接エリア３０２内の車両でエッジ３０８と通信できない車両からの処理要求を処理する。クラウド３０６はさらに、エッジ３０８からの処理依頼についても処理する。もともとエッジ３０８の管轄範囲がクラウド３０６の管轄範囲より狭い上、各車両とエッジ３０８との通信に要する時間も各車両とクラウド３０６との通信に要する時間より短い。そのため、各車両からの処理依頼に対するレスポンスはエッジ３０８の方がクラウド３０６よりも速い。

図３に示す例において、車両３２０の走行エリア３００内には、他の車両３２２および３２４が存在する。また隣接エリア３０２内にも車両３２６および３２８が存在する。このように、ある車両３２０の走行エリアと、その走行エリアに隣接する他の走行エリア内に存在する、車両３２０とは別の車両は、前述したように車両３２０にとっての周辺車両である。各エリア内に存在する車両が、上記した単独型車両、連携型車両、および切替型車両のいずれのタイプであるかは、少なくとも各エリアを管轄するサーバはそれらの位置、移動速度および車種などの車両情報とともに把握し管理している。互いに隣接するエリアを管轄するサーバ間においてそうした車両に関する情報が交換される。したがって、各サーバは少なくとも自分が管轄するエリア内と、そのエリアに隣接するエリア内とに存在する車両の位置、移動方向および速度（これらを車両移動状況という。）とその車両のタイプとを把握し管理している。その結果、例えば車両３２０が周辺車両のタイプおよび車両移動状況などを知りたければクラウド３０４に問い合わせればよい。

図４に、車載エッジ８０を構成するＭＣＵ（Ｍｉｃｒｏ Ｃｏｎｔｒｏｌｌｅｒ Ｕｎｉｔ）のハードウェア構成を示す。図４を参照して、このＭＣＵは、プロセッサであるＭＰＵ（Ｍｉｃｒｏ－Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）４０２と、ＭＰＵ４０２が接続される高速バス４００と、高速バス４００に接続されたＳＲＡＭ（Ｓｔａｔｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）４０４と、高速バス４００に接続されたフラッシュメモリ４０６と、高速バス４００に接続されたＲＯＭ（Ｒｅａｄ－Ｏｎｌｙ Ｍｅｍｏｒｙ）４０８とを含む。ＳＲＡＭ４０４には、プログラムの実行に必要なデータなどが保持される。フラッシュメモリ４０６には、車載エッジ８０が実現する機能を実現するためのプログラム（リアルタイムアプリおよび非リアルタイプアプリの双方を含む。）、リソース制御のためのプログラムなどからなるプログラム４２６が記憶される。ＲＯＭ４０８にはＭＰＵ４０２のブートアッププログラムなどが記憶される。

ＭＣＵはさらに、高速バス４００にブリッジ４１２を介して接続された低速バス４１０と、いずれも低速バス４１０に接続されたシリアルＩ／Ｆ（Ｉｎｔｅｒｆａｃｅ）４１４、ＡＤＣ（Ａｎａｌｏｇ－ｔｏ－Ｄｉｇｉｔａｌ Ｃｏｎｖｅｒｔｅｒ）４１６、タイマ・カウンタ４１８、クロック発生器４２０、電源制御部４２２および汎用Ｉ／Ｆ４２４を含む。

なお、ＭＣＵの動作はよく知られており、実施形態において意味があるのはその実行するプログラムの機能なので、以下説明においてはＭＣＵ自体の動作については説明しない。

図５に、車載エッジ８０の機能的構成をブロック図形式で示す。図５を参照して、機能的には、車載エッジ８０は、車載エッジ８０の起動時に、車載エッジ８０が実現する各機能への自車両または通信可能なサーバのリソースの初期割当を実行するための初期割当部４５２、および図２に示す無線通信部１０６に接続された通信処理部４５０を含む。

車載エッジ８０はさらに、通信処理部４５０に接続され、走行エリア３００内の切替型車両および連携型車両の数に生じた変化（増加および減少）を検出または予測するための変化検出部４５４、および、変化検出部４５４が変化を検出または予測したことに応答して、車載エッジ８０が提供するアプリに対し、自車両およびサーバのリソースを変化後の状況に従って再割当する再割当部４５６を含む。

車載エッジ８０はさらに、リアルタイムアプリおよび非リアルタイムアプリを記憶するためのアプリ記憶部４６２、初期割当部４５２によるリソースの初期割当および再割当部４５６によるリソースの再割当に応答して、アプリ記憶部４６２から読み出したアプリを割当られたリソース（自車両またはサーバ）にそれぞれ実行させるよう、アプリの実行を制御するためのアプリ制御部４５８を含む。車載エッジ８０はさらに、アプリ制御部４５８により自車両のリソースにより実行するように指定されたアプリを実行するためのアプリ実行部４６０を含む。アプリ実行部４６０は、例えば図２に示すＥＣＵ１０２および自動運転ＥＣＵ１０４などを含む。

アプリ制御部４５８によりサーバで実行するよう指定されたアプリは、通信処理部４５０および図２に示す無線通信部１０６を経てサーバに送信され、サーバで実行される。または、アプリ制御部４５８がアプリの識別子をサーバに送信することで、サーバにおいて同等の機能を持つアプリが実行される。

アプリへのリソースの割当は、走行エリア内の連携型車両および切替型車両の数の増減、およびサーバの構成により異なる。図６に、サーバ構成と、各サーバ構成における遅延特性、リアルタイムアプリの実行の可否、および対象エリア（サーバの管轄エリア）の大きさを表形式で示す。

図６に示すように、この実施形態においては、サーバの構成として、クラウドのみ、クラウドとエッジ、１つのエッジのみ、および複数のエッジと複数のクラウドとの任意の組み合わせを考える。これらのうち、クラウドのみを使用する場合には遅延が大きく、エッジを使用する場合には、遅延は小または中程度である。複数クラウドと複数エッジとの組み合わせの場合には、その組み合わせ方により遅延は異なってくる。したがって、サーバ構成がクラウドのみを含む場合はリアルタイムアプリの実行はできないことになる。

図７に、周辺車両に含まれる車両のタイプごとに、走行エリアに関係する車両移動の状況変化および予測ならびにサーバのリソース状況に応じ、どのようにリソースを切り替えるべきかを表形式により示す。

図７の１行目を参照して、例えば、周辺車両が単独型のみであり連携型および切替型車両が存在しない場合には、走行エリアに周辺車両が進入した場合には、サーバのリソース状況には変化は生じない。走行エリアから周辺車両が退出した場合、自車両が走行エリアから隣接エリアのいずれかに移動した場合、またはそうした移動が予測される場合も同様である。したがって自車両（切替型車両）においてリソースの切替の必要はない。

一方、例えば周辺車両に連携型車両が存在している場合を考える。ここで、周辺車両は他に単独型を含んでもよいが、切替型車両は含まないものとする。この場合、自車両の走行エリア内の連携型車両の数が増加する場合および減少する場合の、サーバのリソース状況と切替パターンとを図７の第２行目および第３行目に、それぞれ示す。

自車両の走行エリア内の連携型車両の数が増加する場合とは、例えば隣接エリア内にいる連携型車両が走行エリアに進入する場合または進入することが予測される場合である。他の例としては、自車両が現在の走行エリアから隣接する他の走行エリアに移動しまたは移動が予測される場合であって、その移動先エリア内に、現在の走行エリア内の連携型車両より多くの連携型車両が存在する場合である。この場合には、サーバにおいて利用可能なリソースは一般的に減少し、場合によりサーバのリソースは利用できなくなる。そのときにはサーバのリソースが割り当てられていたアプリにはサーバか自車両のリソースを割り当て直すこと、つまりそのアプリを自車両における処理に切り替える必要がある。

自車両の走行エリア内の連携型車両の数が減少する場合とは、例えば走行エリア内にいる連携型車両が走行エリアから退出する場合または退出することが予測される場合である。他の例としては、自車両が現在の走行エリアから隣接する他の走行エリアに移動しまたは移動が予測される場合であって、その移動先エリア内に存在する連携型車両の数が、現在の走行エリア内の連携型車両の数より少ない場合である。この場合には、サーバにおいて利用可能なリソースは一般的に増加する。その場合、自車両のリソースが割り当てられていた非リアルタイムアプリにサーバのリソースを割り当てることができる可能性がある。したがって、もしもサーバのリソースに余裕があるなら、自車両のリソースが割り当てられていたアプリにサーバのリソースを割り当て直すこと、つまりそのアプリをサーバにおける処理に切り替えることができる。

図７の４行目、５行目、および６行目に記載された情報も同様に解釈できる。ただし、この場合には他の切替型車両が関係してくる。他の切替型車両でも、自車両と同様にリソースの再割当をしようとする。そのために切替型車両の間でサーバのリソースの再割当に競合が発生する可能性がある。そのような場合、切替型車両の間でリソースに関する調整が必要となる。

２Ｃ プログラム構成
図５に示す車載エッジ８０の各機能を実現するために図４に示すＭＰＵ４０２が実行するプログラムの制御構造を、図８以下に示す。

図８を参照して、このプログラム５００は、起動とともにサーバとの通信を開始するステップ５１０および５１０に続き、車載装置が利用する機能を実現する各アプリについて、自車両のリソースとサーバのリソースとの初期割当を行うステップ５１２とを含む。ステップ５１２において行われる割当処理はどのような方法によるものであってもよい。例えば、利用可能なリソースをサーバに問い合せ、サーバに許可された範囲のリソースを非リアルタイムアプリに割り当て、残りのアプリには自車両のリソースを割り当てることが考えられる。なお、プログラム５００の起動時には、車載装置が通信を開始するサーバは図３に示すクラウド３０４であることを想定している。

このプログラムはさらに、サーバから走行エリアを含む周辺エリアの車両情報をダウンロードするステップ５１４と、ステップ５１４においてダウンロードした情報に基づいて、走行エリア内の連携型車両または切替型車両の数に変化が検出または予測されたことに応答してリソースの割当処理を再実行し制御をステップ５１４に戻すステップ５１６とを含む。走行エリア内の連携型車両または切替型車両の数に変化が関係されない場合には、制御はステップ５１４に戻る。

図９を参照して、図８に示す割当処理を再実行するステップ５１６は以下のような制御構造を持つ。ステップ５１６は、周辺車両のエッジ装置の種別をステップ５１４においてダウンロードした車両情報に基づいて観測し判別するステップ５５０と、ステップ５５０の判別結果に基づいて、周辺車両に単独型車両以外の車両、すなわち切替型車両または連携型車両が存在するか否かを判定しその結果に従って制御の流れを分岐させるステップ５５２とを含む。

ステップ５５２において周辺車両に切替型車両または連携型車両が存在すると判定されたときには制御はステップ５５４に進む。ステップ５５４において、ＭＰＵ４０２は、周辺車両に切替型車両が存在するか否かに従って制御の流れを分岐させる。切替型車両が存在すれば、制御はステップ５５６に進み、ＭＰＵ４０２は切替型の周辺車両があるときの処理を実行し、ステップ５１６を終了する。切替型車両がなければ制御はステップ５５８に進み、ＭＰＵ４０２は切替型の周辺車両がないときの処理を実行し、ステップ５１６を終了する。

ステップ５５２において周辺車両に切替型車両または連携型車両が存在しないと判定された場合、周辺車両は単独型車両および車載エッジを持たない車両のみということである。それら周辺車両がサーバのリソースを使用することはない。そのため、ＭＰＵ４０２が自車両の各機能へのリソースの再割当を行う必要はない。したがってこの場合にＭＰＵ４０２はステップ５１６の処理を終了する。

図１０を参照して、図９のステップ５５６は以下のような制御構造を持つ。ステップ５５６は、自車両がエリアを移動予定か否かにもとづいて制御の流れを分岐させるステップ５８０と、ステップ５８０における判定が肯定のときに、移動先のエリア内の切替型車両および連携型車両の数がしきい値以上か否かに従って制御の流れを分岐させるステップ５８２とを含む。ステップ５５６はさらに、ステップ５８０の判定が否定のときに、走行エリアに切替型車両または連携型車両が進入したかまたは進入見込みか否かに従って制御の流れを分岐させるステップ５８４を含む。

ステップ５８２の判定が肯定のとき、およびステップ５８４の判定が肯定のときには制御はステップ５８６に進む。ステップ５８６においてＭＰＵ４０２は、サーバの処理リソースに余裕がないか、または余裕がなくなる見込みか否かを判定して制御の流れを分岐させる。ステップ５８６の判定が否定のときにはステップ５５６は終了する。すなわちこの場合、リソースの再割当は行われない。

ステップ５８６の判定が肯定のときには、制御はステップ５８８に進む。ＭＰＵ４０２は、ステップ５８８において、切替型の周辺車両とリソースの割当の調整を行う。さらに制御はステップ５９０に進み、ＭＰＵ４０２はステップ５８８における調整結果にしたがい、サーバのリソースが割り当てられていたアプリの一部または全部に、自車両のリソースを割り当てる再割当処理を行ってステップ５５６を終了する。なお、ステップ５８８における調整結果によっては、ステップ５９０においてリソースの再割当がされない場合もあり得る。

図１１を参照して、図１０のステップ５８４における判定が否定のときには、制御は図１１のステップ５９４に進む。ステップ５９４においてＭＰＵ４０２は、走行エリアから切替型車両または連携型車両が退出したか、または退出見込みかを判定し、その結果に従って制御の流れを分岐させる。ステップ５９４の判定が否定のときには、ＭＰＵ４０２はステップ５５６の処理を終了する。

このプログラムはさらに、図１０に示すステップ５８２における判定が否定のとき、または図１１のステップ５９４の判定が肯定のときに実行され、サーバにおけるリソースに余裕ができたか、またはできる見込みか否かを判定しその結果に従って制御の流れを分岐させるステップ５９６を含む。ステップ５９６の判定が否定ならＭＰＵ４０２はステップ５５６を終了させる。ステップ５９６の判定が肯定なら、ＭＰＵ４０２はステップ５９８において切替型の周辺車両とサーバリソースの割当について調整する。ＭＰＵ４０２はさらに、ステップ６００において、ステップ５９８における調整結果に従って、アプリの一部にサーバのリソースを割り当ててステップ５５６を終了させる。

図１２に、図９に示すステップ５５８を実現するプログラムの制御構造を示す。図１２を参照して、切替型の周辺車両が存在しないときの処理を実現するステップ５５８は、自車両が他の走行エリアに移動予定か否かに従って制御の流れを分岐させるステップ６３０と、ステップ６３０の判定が肯定のときに、移動先エリア内に存在する連携型車両の数がしきい値以上か否かを判定しその結果に従って制御の流れを分岐させるステップ６３２とを含む。ステップ５５８はさらに、ステップ６３０の判定が否定のときに、走行エリアに連携型の周辺車両が進入したかまたは進入見込みかを判定し、その結果に従って制御の流れを分岐させるステップ６３４を含む。

ステップ５５８はさらに、ステップ６３２における判定が肯定のとき、またはステップ６３４における判定が肯定のときに、サーバ処理リソースに余裕がないか、または余裕がなくなる見込みか否かに従って制御の流れを分岐させるステップ６３６を含む。ステップ６３６の判定が否定ならばステップ５５８は終了する。ステップ６３６の判定が肯定なら、制御はステップ６３８に進み、ＭＰＵ４０２はサーバのリソースが割り当てられていたアプリの一部または全部について自車両のリソースに切り替えてステップ５５８を終了する。

図１３を参照して、ステップ５５８はさらに、図１２のステップ６３４における判定が否定であることに応答して実行され、走行エリアから連携型車両が退出したかまたは退出が予測されるかに従って制御の流れを分岐させるステップ６４２を含む。

ステップ６３２の判定が否定、またはステップ６４２の判定が肯定ならば、制御はステップ６４４に進む。ＭＰＵ４０２は、ステップ６４４において、サーバの処理リソースに余裕ができたか、またはできる見込みか否かを判定して制御の流れを分岐させる。ステップ６４４における判定が否定ならサーバの処理リソースに余裕がないのでステップ５５８は終了する。ステップ６４４における判定が肯定なら、制御はステップ６４６に進みサーバのリソースをアプリに割り当てる処理を実行する。ステップ６４６が完了するとステップ５５８は終了する。ステップ６４６の詳細については図１５を参照して後述する。

ステップ６４２の判定が否定の場合には、ステップ５５８は終了する。

図１４に、切り替え先のサーバ構成の種類に対し、切替型の車両がリアルタイムアプリと非リアルタイムアプリとのリソースをどのような方針に従って割り当てるかについて表形式により示す。図１４を参照して、例えば、切替先のサーバがクラウドのみを含む場合（１行目）、クラウドによってはリアルタイムアプリの実行は不可である。したがってＭＰＵ４０２はリアルタイムアプリには自車両のリソースを割り当てる。一方、非リアルタイムアプリには基本的にクラウドのリソースを割り当てる。

第２行目に示すように、サーバがエッジとクラウドとの二層構造となっている場合、エッジはリアルタイムアプリを実行できる。したがって、切替型の車両は、リアルタイムアプリにはエッジのリソースを割り当てる。一方、非リアルタイムアプリはエッジでもクラウドでも処理可能である。したがって、それぞれで利用可能なリソースに応じて、エッジのリソースまたはクラウドのリソースを非リアルタイムアプリに割り当てる。

第５行目には、サーバが複数エッジと複数クラウドとの双方を有するものと、複数クラウドのみを有するものとが組み合わされたものである場合についてのリソース割当方針を示す。この場合、サーバ構成にエッジが含まれるような環境であるときにはサーバ側（エッジ）においてリアルタイムアプリを実行できる。したがって、ＭＰＵ４０２はリアルタイムアプリにエッジのリソースを割り当てる。しかしサーバ構成がクラウドのみを含む場合には、サーバ側においてリアルタイムアプリは実行できない。したがってこの場合、ＭＰＵ４０２はリアルタイムアプリに自車両のリソースを割り当てる。そしていずれの場合も、ＭＰＵ４０２は、非リアルタイムアプリには利用可能なサーバ側のリソースを割り当てる。

図１５に、図１３のステップ６４６において実行されるプログラムの制御構造を示す。図１５を参照して、アプリに割り当てるリソースをサーバ側に切り替えるステップ６４６は、サーバ構成にエッジが含まれるか否かを判定しその結果に従って制御の流れを分岐させるステップ６８０と、ステップ６８０の判定が否定であることに応答して、リアルタイムアプリには自車両のリソースを割り当て、非リアルタイムアプリにはクラウドのリソースを割り当てるステップ６８４とを含む。ステップ６８４においては、ＭＰＵ４０２を搭載した車両の走行エリアを管轄しているサーバがクラウドを含むことを想定している。

ステップ６８０における判定が肯定のときには制御はステップ６８２に進む。ＭＰＵ４０２はステップ６８２において、サーバ構成にクラウドがあるか否かを判定しその結果に従って制御の流れを分岐させる。

ステップ６８２における判定が否定のときには制御はステップ６８６に進む。ステップ６８２における判定が否定であるということは、サーバ構成がエッジのみということである。したがって、ステップ６８６においてＭＰＵ４０２は、リアルタイムアプリにはエッジのリソースを割り当て、非リアルタイムアプリについてもエッジのリソースを割り当ててステップ６４６の処理を終わる。

一方、ステップ６８２における判定が肯定であるときには制御はステップ６８８に進む。ステップ６８２における判定が肯定であるということは、サーバ構成がクラウドとエッジの双方を含むということである。したがってＭＰＵ４０２は、ステップ６８８においてリアルタイムアプリにはエッジのリソースを割り当て、非リアルタイムアプリにはエッジのリソースの状況に応じ、エッジまたはクラウドのリソースを割り当ててステップ６４６の処理を終わる。

図１６には、切替先のサーバのリソースの状況に応じて、切替型車両が各アプリにどのようにリソースを割り当てるかを表形式により示す。図１６を参照して、例えば１行目には、ＭＰＵ４０２がエッジまたはクラウドに対してリソースの割り当て要求を行ったときに、エッジが全ての要求を受け入れ可能である場合が示されている。この場合にはクラウドは要求を受け入れる必要はない。切替型車両は、リアルタイムアプリにはエッジのリソースを割り当てる。切替型車両は、非リアルタイムアプリにもエッジのリソースを割り当てる。

第２行目はエッジが割当要求の一部のみの受け入れが可能な場合である。この場合、リアルタイムアプリについては、切替型車両（自車両）は、切替型の周辺車両とリソース割当の優先度を調整する。切替型車両は、調整結果に、リアルタイムアプリのうち、エッジのリソースの割り当てが可能な部分についてはエッジのリソースを割り当てる。切替型車両は、リアルタイムアプリの残りに付いては自車両のリソースを割り当てる。

一方、エッジが割当要求の一部のみの受け入れが可能な場合には、非リアルタイムアプリについてはクラウドの状況によりさらに３つの場合に分けられる。第１はクラウドが割当要求を全て受け入れ可能な場合である。このとき、切替型車両は非リアルタイムアプリの全てにクラウドのリソースを割り当てる。第２はクラウドがリソースの割り当て要求のうち一部のみを受け入れ可能な場合である。このとき、切替型車両は切替型の周辺車両とリソースの割り当てに関する優先度を調整する。切替型車両はさらに、この調整の結果に、非リアルタイムアプリのうちクラウドが受け入れ可能な部分についてはクラウドのリソースを割り当てる。切替型車両は、非リアルタイムアプリの残りについては自車両のリソースを割り当てる。第３は、クラウドがリソースの割り当て要求を受け入れ不可能な場合である。この場合には切替型車両は全ての非リアルタイムアプリに自車両のリソースを割り当てる。

エッジがリソースの割当要求の受け入れができないときが第３行目に示されている。この場合には、クラウドがリソースの割当要求を全て受け入れ可能か否かにかかわらず、リアルタイムアプリの全てに自車両のリソースが割り当てられる。非リアルタイムアプリについては、クラウドが割り当て要求を全て受け入れ可能か、一部のみ可能か、不可かによりリソースの割り当ては異なってくる。クラウドがリソースの割り当て要求を一部のみ受け入れ可能な場合には、切替型車両は切替型の周辺車両と優先度を調整する。切替型車両はその調整の結果に従って、非リアルタイムアプリの中でクラウドのリソースが割り当て可能な部分にはクラウドのリソースを割り当てる。切替型車両は、非リアルタイムアプリの残りには自車両のリソースを割り当てる。

図１７に、図１０のステップ５８８および図１１のステップ５９８において実行される、切替型の周辺車両との優先度の調整を実現するプログラムの制御構造をフローチャート形式により示す。図１７を参照して、このプログラムは、エッジがリソースの割り当て要求を全て受け入れ可能か否かを判定しその結果に従って制御の流れを分岐させるステップ７１０と、ステップ７１０の判定が肯定のときに、リアルタイムアプリにエッジのリソースを割り当て、非リアルタイムアプリにもエッジのリソースを割り当てて処理を終了するステップ７１４とを含む。

このプログラムはさらに、ステップ７１０に否定のときに、エッジがリソースの割当要求を一部のみ受け入れ可能か否かを判定しその結果に従って制御の流れを分岐させるステップ７１２を含む。ステップ７１２の判定が肯定の場合、制御はステップ７１６に進む。ステップ７１６においてＭＰＵ４０２は、エッジを使用するようにリソースの割り当てを行う。ステップ７１２の判定が否定ならば制御はステップ７１８に進む。ステップ７１８においてＭＰＵ４０２は、エッジを使用しないようにリソースの割り当てを行う。

図１８に、図１７のステップ７１６において行われる、エッジを使用するようにリソースを割り当てる処理を実現するプログラムの制御構造を示す。図１８を参照して、このプログラムは、クラウドがリソースの割当要求を全て受け入れ可能か否かを判定しその結果に従って制御の流れを分岐させるステップ７５０と、ステップ７５０の判定が肯定のときに、リアルタイムアプリに関する割当を行うステップ７５４と、ステップ７５４に続き、非リアルタイムアプリにクラウドのリソースを割り当ててステップ７１６を終了するステップ７５６とを含む。

このプログラムはさらに、ステップ７５０における判定が否定のときに、クラウドがリソースの割当要求の一部のみ受け入れ可能か否かに従って制御の流れを分岐させるステップ７５２を含む。ステップ７５２の判定が肯定のときには制御はステップ７５８に進む。ステップ７５２の判定が否定のときには制御はステップ７６２に進む。

ステップ７５８においてＭＰＵ４０２は、リアルタイムアプリに関する優先度処理を実行する。続くステップ７６０においてＭＰＵ４０２は、非リアルタイムアプリに関する優先度処理を実行してステップ７１６を終了する。一方、ステップ７６２においてＭＰＵ４０２は、リアルタイムアプリに関する優先度処理を行う。続くステップ７６４においてＭＰＵ４０２は、非リアルタイムアプリに自車両のリソースを割り当ててステップ７１６を終了する。

図１９に、ＭＰＵ４０２が図１８のステップ７５４、７５８および７６２において実行する、リアルタイムアプリに関する優先度処理のプログラムの詳細を示す。図１９を参照して、このプログラムは、走行エリア内に存在する切替型車両と、優先度を決定するために必要な情報を交換するステップ８００と、ステップ８００により他の切替型車両から受信した情報を自車両に関する情報とを用いて、各車両の優先度を決定するステップ８０２とを含む。

ここでいう優先度を決定するためには、様々な基準を利用できる。たとえば緊急車両の優先度が最も高く、事業者の車両の優先度が次に高く、自家用車両の優先度が最も低くなるようにする方法が考えられる。または、サーバ利用のために、各車両の所有者に何らかの課金をすることを考える。この場合には、課金の額が高くなるほど優先度を高くする。これらとは別に、各車両において利用可能なリソースを比較し、リソースに余裕がない車両ほど高い優先度を付与する方法も可能である。さらに、サーバが管理するエリア内を今後走行する時間が長い車両ほど、高い優先度を付与する方法を採用してもよい。また、これらを任意に組み合わせて何らかのスコアを算出するようにし、そのスコアの値が高い車両ほど高い優先度が割り当てられるような方法を採用することも考えられる。

このプログラムはさらに、ステップ８０２に続き、ステップ８０２において決定された優先度に従い、優先度の上位の切替型車両から順番に、エッジのリソースが利用可能な限り、リアルタイムアプリにエッジのリソースを割り当てる演算を繰り返し、その過程において自車両のリアルタイムアプリにエッジのリソースを割り当てるステップ８０４と、ステップ８０４に続き、自車両のリアルタイムアプリの中でエッジのリソースが割り当てられないものに自車両のリソースを割り当ててこの処理を終了するステップ８０６とを含む。

図２０に、図１８のステップ７６０において実行される非リアルタイムアプリに関する優先度処理の詳細を示す。図２０を参照して、ステップ７６０は、ＭＰＵ４０２が、優先度を決定するための情報を走行エリア内の他の切替型車両および走行エリア内に進入が予測される他の切替型車両と交換するステップ８３０と、ステップ８３０において交換された情報に基づいて、ＭＰＵ４０２が各切替型車両の優先度を決定するステップ８３２とを含む。

ステップ７６０はさらに、ステップ８３２において算出された優先度に従い、優先度が上位の切替型車両から順番に、クラウドのリソースが利用な限り非リアルタイムアプリにクラウドのリソースを割り当てるステップ８３４と、ステップ８３４に続き、自車両の非リアルタイムアプリの中で、クラウドのリソースが割り当てられないものに自車両のリソースを割り当ててステップ７６０を終了するステップ８３６とを含む。

図２１に、図１７のステップ７１８の詳細を示す。図２１を参照して、ステップ７１８は、クラウドが全ての割当要求を受け入れ可能か否かを判定しその結果に従って制御の流れを分岐させるステップ８６０を含む。ステップ８６０の判定が肯定のときには、ＭＰＵ４０２はステップ８６４においてリアルタイムアプリに自車両のリソースを割り当てる。ＭＰＵ４０２はさらに、ステップ８６６において非リアルタイムアプリにクラウドのリソースを割り当ててステップ７１８を終了するステップ８６６を含む。

ステップ８６０の判定が否定のときには、ＭＰＵ４０２はさらに、ステップ８６２において、クラウドが一部の割当要求のみ受け入れ可能か否かに従って制御の流れを分岐させる。ステップ８６２の判定が肯定のときには制御はステップ８６８に進む。ＭＰＵ４０２は、ステップ８６８において、リアルタイムアプリに自車両のリソースを割り当てる。ＭＰＵ４０２はさらに、ステップ８７０において、非リアルタイムアプリに関する優先度処理を実行してステップ７１８を終了するステップ８７０を含む。ステップ８７０は図２０に示すステップ７６０と同じである。

ステップ８６２の判定が否定のときには、ＭＰＵ４０２は、ステップ８７２においてリアルタイムアプリに自車両のリソースを割り当てる。ＭＰＵ４０２はさらに、続くステップ８７４において非リアルタイムアプリに自車両のリソースを割り当ててステップ７１８を終了する。

３ 動作
以上に構成を述べた車載エッジ８０（図５参照）は、以下のように動作する。図８を参照して、車両３２０の初期割当部４５２は、車載エッジ８０が動作を開始した時点（図８の処理開始時点）で、車両３２０が存在しているエリアを管轄しているサーバ（例えば図３に示すクラウド３０４）との通信を開始する（図８のステップ５１０）。初期割当部４５２はサーバから得た情報に基づいて、何らかの方法により、車両３２０のリアルタイムアプリと非リアルタイムアプリへのリソースの割当処理を行う（ステップ５１２）。アプリ制御部４５８はこの割当結果に従い、クラウドまたはエッジのリソースが割り当てられたアプリをアプリ記憶部４６２から読み出して、通信処理部４５０を通じクラウドまたはエッジに送信し実行を依頼する。この場合、クラウドのリソースが割り当てられるアプリは非リアルタイムアプリである。エッジのリソースが割り当てられたアプリは、リアルタイムアプリであることも、非リアルタイムアプリであることもある。エッジが存在しない場合には、リアルタイムアプリには自車両のリソースが割当てられる。アプリ制御部４５８は、自車両のリソースが割り当てられたアプリはアプリ記憶部４６２から読み出してアプリ実行部４６０に実行させる。車載エッジ８０はその後、この時点まで、各走行エリアを管轄するサーバから周辺車両に関する情報および運転支援に関する情報をダウンロードし（ステップ５１４）、この情報通信にもとづいて各アプリへのリソースの再割当を実行する（ステップ５１６）、という処理を繰り返す。

ここでは例えば図３に示すように、車両３２０が走行エリア３００内を走行中であるものとし、走行予定にある時間ｔ１後に隣接エリア３０２に移動することが予測されたものとする。走行エリア３００はクラウド３０４が管轄している。隣接エリア３０２はクラウド３０６およびエッジ３０８が連携して管轄している。

図３に示す状況において、例えば走行エリア３００内の車両３２４は単独型であり、車両３２２は切替型であるものとする。車両３２４は近い将来に走行エリア３００から退出が予測される。車両３２２は車両３２０の後ろを走行している。したがって、車両３２２は走行エリア３００からはしばらくの間、退出しないことが予測される。また、隣接エリア３０２内には切替型車両３２６および３２８が存在しているものとする。これらのうち、車両３２６は走行エリア３００から遠ざかる方向に走行している。車両３２８は現時点から時間ｔ２だけ経過した後、隣接エリア３０２から走行エリア３００に進入することがエッジ３０８およびクラウド３０６により予測されている。ここではｔ２＜ｔ１とする。また時間ｔ１後にもまだ車両３２６は隣接エリア３０２内にとどまっていることがエッジ３０８により予測されている。

図５を参照して、車両３２０の変化検出部４５４は、走行予定に従えば時間ｔ２後に切替型の車両３２８が走行エリア３００に進入することを予測する。この場合、走行エリア３００内における切替型車両の数が２から３に増加する。変化検出部４５４は、この変化を検出したことに応答して、再割当部４５６に切替型車両の増加を通知する。再割当部４５６は、この通知に応答して、車両３２０のリアルタイムアプリおよび非リアルタイムアプリへのリソースの再割当処理を実行する。アプリ制御部４５８はこの再割当の結果にしたがい、非リアルタイムアプリの中でクラウド３０４のリソースが割り当てられたアプリはクラウド３０４に実行を依頼し、車両３２０のリソースが割り当てられたアプリはそのリソースにそのアプリを実行させる。

なお、図３に示す車両３２２および３２８および車両３２６においても同様の処理が実行される。車両３２８が隣接エリア３０２から走行エリア３００に進入すると、車両３２８の走行エリア内の切替型車両の数は２から３に増加する。そのため、車両３２２および３２８においては上記したよう車両３２０と同様の処理が実行される。また車両３２６にとっては、走行エリア内の切替型車両の数が２から１に減少する。したがって車両３２６においてもリソースの再割当が実行される。この場合、車両３２８がどのようなアプリにクラウド３０６およびエッジ３０８のリソースを割り当てていたかにより異なるが、一般的には車両３２６はより多くのアプリにクラウド３０６およびエッジ３０８のリソースを割り当てることになる。

さらに、車両３２８が走行エリア３００に進入した後、車両３２０が隣接エリア３０２に移動したものとする。この場合、車両３２０にとっての走行エリアが走行エリア３００から隣接エリア３０２に変化する。車両３２０の走行エリア内の切替型車両の数は３から２に変化する。したがって、車両３２０はリソースの再割当処理を実行する。車両３２６においても同様であり、隣接エリア３０２内の切替型車両の数が１から２に増加したことを検出してリソースの再割当処理を実行する。その過程で、車両３２６と車両３２０との間で優先度の算出が行われ、その結果に従って車両３２６と車両３２０との双方においてクラウド３０６およびエッジ３０８のリソースの再割当が実行される。

一方、車両３２０が隣接エリア３０２に移動したことにより、走行エリア３００内の切替型車両の数が３から２に減少する。その結果、車両３２２および３２８においてもリソースの再割当処理が実行される。

なお、エリア間を移動する車両が単独型ならば、サーバにおいて利用可能なリソースに変化は生じない。したがってこの場合には切替型車両においてリソースの再割当処理は実行されない。一方、エリア間を移動する車両が連携型車両の場合には事情が異なる。あるエリアに進入する車両が連携型車両ならば、固定した量のサーバのリソースがその連携型車両に割り当てられる。逆にあるエリアから退出する車両が連携型車両ならば、固定した量のサーバのリソースが利用可能になる。したがってこれらの場合に、そのエリア内に連携型車両が存在する場合には、いずれの場合もリソースの再割当処理が実行されることになる。

以上のようにこの実施形態によれば、走行エリア内に存在する連携型車両および切替型車両の数の変化に応じて、切替型車両において、アプリに対するサーバのリソースと自車両のリソースとの再割当が実行される。その結果、サーバのリソースを車両の各アプリの間で柔軟に配分することにより、サーバのリソースを有効に利用して各車両の処理負担を軽減し、様々な機能を柔軟に提供できるという効果がある。

第２ 変形例
上記実施形態においては、切替型車両は、サーバを通じて周辺車両の車両移動状況などの情報を入手するものとした。しかしこの開示はそのような形態には限定されない。切替型車両は、他車両とのいわゆる車々間通信により、直接に周辺車両の車両移動状況などの情報を入手してもよい。ただしこの場合、単独型車両、およびそもそも車載エッジを搭載していない車両については、少なくともそれらの車両移動状況についてサーバを通じて入手するか、自車両のセンサデータに基づいて算出する必要がある。または切替型車両は、路側装置などのいわゆるインフラ設備との通信により他車両の車両移動状況などの情報を入手してもよい。

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

今回開示された実施の形態は全ての点で例示であって制限的なものではないと考えられるべきである。本開示の範囲は、開示の詳細な説明の記載により示されるわけではなく、請求の範囲の各請求項によって示され、請求の範囲の文言と均等の意味および範囲内での全ての変更が含まれることが意図される。

６０、７０、８０ 車載エッジ
７２、８２ サーバ
１００ センサ
１０２ ＥＣＵ
１０４ 自動運転ＥＣＵ
１０６ 無線通信部
１０８ 車載ＧＷ
３００ 走行エリア
３０２ 隣接エリア
３０４、３０６ クラウド
３０８ エッジ
３２０、３２２、３２４、３２６、３２８ 車両
４００ 高速バス
４０２ ＭＰＵ
４０４ ＳＲＡＭ
４０６ フラッシュメモリ
４０８ ＲＯＭ
４１０ 低速バス
４１２ ブリッジ
４１４ シリアルＩ／Ｆ
４１６ ＡＤＣ
４１８ タイマ・カウンタ
４２０ クロック発生器
４２２ 電源制御部
４２４ 汎用Ｉ／Ｆ
４２６、５００ プログラム
４５０ 通信処理部
４５２ 初期割当部
４５４ 変化検出部
４５６ 再割当部
４５８ アプリ制御部
４６０ アプリ実行部
４６２ アプリ記憶部

Claims (18)

1. サーバとの通信により運転支援機能を提供する車載装置におけるリソース割当方法であって、
   前記車載装置は、前記車載装置を搭載した車両の走行エリアを管轄するサービス提供装置のリソースと前記車載装置を搭載した車両である自車両のリソースとを切り替えて前記車載装置の各機能に割り当てる切替型車載装置であり、
   前記リソース割当方法は、
   コンピュータが、前記自車両の走行エリアを管轄するサービス提供装置であるサーバのリソースと、前記自車両のリソースとを前記車載装置の各機能に割り当てる割当処理を実行するステップと、
   コンピュータが、前記走行エリア内に存在している、前記サーバとの連携を行う車両の数の変化を検出または予測したことに応答して、前記割当処理を再実行するステップとを含む、リソース割当方法。
2. 前記再実行するステップは、
   コンピュータが、前記走行エリアと前記走行エリアに隣接する隣接エリアとを含む周辺エリア内に存在する各車両が、サービス提供装置との連携を行なわない単独型車両、リソースの固定的な割当を使用してサービス提供装置と連携する連携型車両、および前記切替型車載装置を搭載する切替型車両のいずれであるかを判別するステップと、
   コンピュータが、前記周辺エリア内に前記単独型車両以外の車両が存在するか否かを判定する第１判定ステップと、
   コンピュータが、前記第１判定ステップにおいて前記周辺エリア内に前記単独型車両以外の車両が存在すると判定されたことに応答して、前記サーバにおいて利用可能なリソースに応じて、前記自車両のリソースと前記サーバのリソースとを前記車載装置の各機能に再割当する処理を実行するステップとを含む、請求項１に記載の方法。
3. 前記再割当する処理を実行するステップは、
   コンピュータが、前記周辺エリア内に前記自車両以外に前記切替型車両が存在しているか否かを判定する第２判定ステップと、
   コンピュータが、前記第２判定ステップにおける判定が肯定であることに応答して、前記周辺エリア内に存在する前記切替型車両との前記サーバのリソースに関する調整結果と、前記サーバにおいて利用可能なリソースの状況とに基づき、前記サーバのリソースと、前記自車両のリソースとを前記車載装置の各機能に再割当する処理を実行する第１再割当実行ステップと、
   コンピュータが、前記第２判定ステップにおける判定が否定であることに応答して、前記サーバにおいて利用可能なリソースの状況に基づき、前記サーバのリソースと、前記自車両のリソースとを前記車載装置の各機能に再割当する処理を実行する第２再割当実行ステップとを含む、請求項２に記載の方法。
4. 前記第１再割当実行ステップは、
   コンピュータが、前記第２判定ステップにおける判定が肯定であることに応答して、前記走行エリア内に存在する前記連携型車両または前記切替型車両の増加を検出または予測する第１検出ステップと、
   コンピュータが、前記第１検出ステップにおいて前記走行エリア内に存在する前記連携型車両または前記切替型車両の増加が検出または予測されたことに応答して、前記サーバのリソースが不足するか否かを判定する第３判定ステップと、
   コンピュータが、前記第３判定ステップにおける判定結果が肯定であることに応答して、前記周辺エリア内に存在する前記切替型車両との前記サーバのリソースに関する調整を実行し、前記調整の結果に基づいて、前記車載装置の機能に割り当てられていた前記サーバのリソースの少なくとも一部を前記自車両のリソースに切り替えるステップとを含む、請求項３に記載の方法。
5. 前記第１再割当実行ステップは、さらに、
   コンピュータが、前記第２判定ステップにおける判定が肯定であることに応答して、前記走行エリア内に存在する前記連携型車両または前記切替型車両の減少を検出または予測する第２検出ステップと、
   コンピュータが、前記第２検出ステップにおいて前記走行エリア内に存在する前記連携型車両または前記切替型車両の減少が検出または予測されたことに応答して、前記サーバのリソースに余裕が生じるか否かを判定する第４判定ステップと、
   コンピュータが、前記第４判定ステップにおける判定結果が肯定であることに応答して、前記周辺エリア内に存在する前記切替型車両との前記サーバのリソースに関する調整を実行し、前記調整の結果にもとづいて、前記車載装置の機能に割り当てられていた前記自車両のリソースの少なくとも一部を前記サーバのリソースに切り替えるステップと含む、請求項４に記載の方法。
6. 前記第１再割当実行ステップは、
   コンピュータが、前記第２判定ステップにおける判定が肯定であることに応答して、前記走行エリア内に存在する前記連携型車両または前記切替型車両の減少を検出または予測する第２検出ステップと、
   コンピュータが、前記第２検出ステップにおいて前記走行エリア内に存在する前記連携型車両または前記切替型車両の減少が検出または予測されたことに応答して、前記サーバのリソースに余裕が生じるか否かを判定する第３判定ステップと、
   コンピュータが、前記第３判定ステップにおける判定結果が肯定であることに応答して、前記車載装置の機能に割り当てられていた前記自車両のリソースの少なくとも一部を前記サーバのリソースに切り替えるステップとを含む、請求項３に記載の方法。
7. 前記第２再割当実行ステップは、
   コンピュータが、前記第２判定ステップにおける判定が否定であることに応答して、前記走行エリア内に存在する前記連携型車両の増加を検出または予測するエリア内増加検出ステップと、
   コンピュータが、前記エリア内増加検出ステップにおいて前記走行エリア内に存在する前記連携型車両の増加が検出または予測されたことに応答して、前記サーバのリソースが不足するか否かを判定する第１サーバリソース判定ステップと、
   コンピュータが、前記第１サーバリソース判定ステップにおける判定結果が肯定であることに応答して、前記車載装置の機能に割り当てられていた前記サーバのリソースの少なくとも一部を前記自車両のリソースに切り替えるステップとを含む、請求項３から請求項６のいずれか１項に記載の方法。
8. 前記第２再割当実行ステップは、さらに、
   コンピュータが、前記第１サーバリソース判定ステップにおける判定が否定であることに応答して、前記走行エリア内に存在する前記連携型車両の減少を検出または予測するエリア内減少検出ステップと、
   コンピュータが、前記エリア内減少検出ステップにおいて前記走行エリア内に存在する前記連携型車両の減少が検出または予測されたことに応答して、前記サーバのリソースに余裕が生じるか否かを判定する第２サーバリソース判定ステップと、
   コンピュータが、前記第２サーバリソース判定ステップにおける判定結果が肯定であることに応答して、前記車載装置の機能に割り当てられていた前記自車両のリソースの少なくとも一部を前記サーバのリソースに切り替えるステップとを含む、請求項７に記載の方法。
9. 前記第２再割当実行ステップは、
   コンピュータが、前記第２判定ステップにおける判定が否定であることに応答して、前記走行エリア内に存在する前記連携型車両の減少を検出または予測するエリア内減少検出ステップと、
   コンピュータが、前記エリア内減少検出ステップにおいて前記走行エリア内に存在する前記連携型車両の数の減少が検出または予測されたことに応答して、前記サーバのリソースに余裕が生じるか否かを判定する第１サーバリソース判定ステップと、
   コンピュータが、前記第１サーバリソース判定ステップにおける判定結果が肯定であることに応答して、前記車載装置の機能に割り当てられていた前記自車両のリソースの少なくとも一部を前記サーバのリソースに切り替えるステップとを含む、請求項３から請求項６のいずれか１項に記載の方法。
10. 前記走行エリアの前記サーバは、少なくとも第１サーバを含み、
    前記車載装置の機能は、第１機能と、第１機能よりも速いレスポンスを必要とする第２機能とを含み、
    前記サーバのリソースに切り替える前記ステップは、
    前記走行エリアの前記サーバが、前記第１サーバよりレスポンスの速い第２サーバをさらに含むか否かを判定するサーバ構成判定ステップと、
    前記サーバ構成判定ステップにおいて、前記サーバが前記第２サーバを含まないと判定されたことに応答して、前記第２機能に前記自車両のリソースを割り当て、前記第１機能に前記第１サーバのリソースを割り当てるステップとを含む、請求項５または請求項６に記載の方法。
11. 前記サーバのリソースに切り替える前記ステップは、さらに、前記サーバ構成判定ステップにおいて、前記サーバが前記第２サーバを含むと判定されたことに応答して、前記第１機能に前記第１サーバのリソースを割り当て、前記第２機能に前記第２サーバのリソースを割り当てるステップを含む、請求項１０に記載の方法。
12. 前記走行エリアの前記サーバは、少なくとも第１サーバを含み、
    前記車載装置の機能は、第１機能と、第１機能よりも速いレスポンスを必要とする第２機能とを含み、
    前記サーバのリソースに切り替える前記ステップは、
    前記走行エリアの前記サーバが、前記第１サーバよりレスポンスの遅い第２サーバをさらに含むか否かを判定するサーバ構成判定ステップと、
    前記サーバ構成判定ステップにおいて、前記サーバが前記第２サーバを含まないと判定されたことに応答して、前記第１機能および前記第２機能に前記第１サーバのリソースを割り当てるステップとを含む、請求項５または請求項６に記載の方法。
13. 前記サーバのリソースに切り替える前記ステップは、さらに、前記サーバ構成判定ステップにおいて、前記サーバが前記第２サーバを含むと判定されたことに応答して、前記第１機能に前記第２サーバのリソースを割り当て、前記第２機能に前記第１サーバのリソースを割り当てるステップを含む、請求項１２に記載の方法。
14. 前記走行エリアの前記サーバは、第１サーバと、前記第１サーバよりもレスポンスの速い第２サーバとを含み、
    前記車載装置の機能は、第１機能と、第１機能よりも速いレスポンスを必要とする第２機能とを含み、
    前記サーバのリソースに切り替える前記ステップは、
    前記第２機能に前記第２サーバが許す限り多く前記第２サーバのリソースを割り当てるステップと、
    前記第１機能に前記第１サーバおよび前記第２サーバが許す限り多く前記第１サーバのリソースおよび前記第２サーバのリソースを割り当てるステップと、
    前記第２機能の中で前記第２サーバのリソースが割り当てられない機能、および前記第１機能の中で前記第１サーバのリソースも前記第２サーバのリソースも割り当てられない機能に前記自車両のリソースを割り当てるステップとを含む、請求項５または請求項６に記載の方法。
15. 前記第２機能に前記第２サーバが許す限り多く前記第２サーバのリソースを割り当てるステップは、
    前記第２機能の全てに前記第２サーバのリソースが割り当てられるか否かを判定する割当判定ステップと、
    前記割当判定ステップにおいて前記第２機能の全てに前記第２サーバのリソースが割り当てられると判定されたことに応答して、前記第２機能の全てに前記第２サーバのリソースを割り当てるステップと、
    前記割当判定ステップにおいて前記第２機能の少なくとも一部に前記第２サーバのリソースが割り当てられないと判定されたことに応答して、前記走行エリア内の他の前記切替型車両との間で前記第２サーバのリソースの割当の調整を実行し、前記調整の結果に従って前記第２機能の前記一部に前記第２サーバのリソースを可能な限り多く割り当てるステップと、
    前記調整の結果、前記第２機能の中で、前記第２サーバのリソースが割り当てられない機能に前記自車両のリソースを割り当てるステップとを含む、請求項１４に記載の方法。
16. 前記第１機能に前記第１サーバおよび前記第２サーバが許す限り多く前記第１サーバのリソースおよび前記第２サーバのリソースを割り当てるステップは、
    前記第１機能の全てに前記第１サーバのリソースが割り当てられるか否かを判定する追加判定ステップと、
    前記追加判定ステップにおいて第１機能の全てに前記第１サーバのリソースが割り当てられると判定されたことに応答して、前記第１機能の全てに前記第１サーバのリソースを割り当てるステップと、
    前記追加判定ステップにおいて前記第１機能の少なくとも一部に前記第１サーバのリソースが割り当てられないと判定されたことに応答して、前記走行エリア内の他の前記連携型車両および前記切替型車両との間で前記第１サーバのリソースの割当の調整を実行し、前記調整の結果に従って前記第１機能の前記一部に前記第１サーバのリソースを可能な限り割り当てるステップと、
    前記調整の結果、前記第１機能の中で、前記第１サーバのリソースが割り当てられない機能に前記自車両のリソースを割り当てるステップとを含む、請求項１４に記載の方法。
17. サーバとの通信により運転支援機能を提供する車載装置におけるリソース割当装置であって、
    前記車載装置は、前記車載装置を搭載した車両の走行エリアを管轄するサーバのリソースと前記車載装置を搭載した車両である自車両のリソースとを切り替えて前記車載装置の各機能に割り当てる切替型車載装置であり、
    前記リソース割当装置は、
    前記自車両の走行エリアを管轄するサーバのリソースと、前記自車両のリソースとを前記車載装置の各機能に割り当てる割当処理を実行する割当実行部と、
    前記走行エリア内に存在している、サーバとの連携を行う車両の数の変化を検出または予測したことに応答して、前記割当処理を再実行する割当再実行部とを含む、リソース割当装置。
18. コンピュータを、サーバとの通信により運転支援機能を提供する車載装置においてリソースの割当を行うように機能させるコンピュータプログラムであって、
    前記車載装置は、前記車載装置を搭載した車両の走行エリアを管轄するサーバのリソースと前記車載装置を搭載した車両である自車両のリソースとを切り替えて前記車載装置の各機能に割り当てる切替型車載装置であり、
    前記コンピュータプログラムは、コンピュータを、
    前記自車両の走行エリアを管轄するサーバのリソースと、前記自車両のリソースとを前記車載装置の各機能に割り当てる割当処理を実行する割当実行部と、
    前記走行エリア内に存在している、サーバとの連携を行う車両の数の変化を検出または予測したことに応答して、前記割当処理を再実行する割当再実行部として機能させる、コンピュータプログラム。