(57)【特許請求の範囲】
【請求項１】
複数の車載端末から構成され、ユーザ端末からタスクの実行依頼を受け付けて実行する車両システムにおける計算リソース提供方法であって、
車載端末間で、車両が提供可能な計算リソースに関する情報を少なくとも含む情報である車両情報を交換する通知ステップと、
自車両の車両情報および他の車両から送信される車両情報に基づいて、車群を形成および管理する車群形成管理ステップと、
前記車群が前記ユーザ端末と通信可能な時間と当該時間内において提供可能な計算リソースとに関する情報である車群リソース情報を生成する車群リソース情報生成ステップと、
前記車群リソース情報と合致するタスクの実行依頼を前記ユーザ端末から受け付ける実行依頼受信ステップと、
を含む計算リソース提供方法。
【請求項２】
前記ユーザ端末からタスクの実行依頼を受け付けた車載端末が、前記車群リソース情報に基づいて、前記タスクを実行する車載端末を決定する決定ステップと、
前記ユーザ端末からタスクの実行依頼を受け付けた車載端末が、前記決定ステップによって決定された車載端末に前記タスクを移送する移送ステップと、
前記タスクを移送された車載端末が前記タスクを実行する実行ステップと、
をさらに含む、請求項１に記載の計算リソース提供方法。
【請求項３】
前記実行ステップにおける前記タスクの実行完了後に、当該タスクを実行していた車載端末が、前記タスクの計算結果を前記ユーザ端末に送信するステップをさらに含む、
請求項２に記載の計算リソース提供方法。
【請求項４】
前記ユーザ端末からの前記タスクの実行依頼の受け付け後に、前記ユーザ端末と前記車群とが継続して通信可能な時間に関する情報を定期的に算出するステップと、
前記通信可能な時間内にタスクが完了しないと予測される場合は、前記タスクを実行している車載端末が、前記タスクの途中結果を前記ユーザ端末に送信するステップと、
をさらに含む、請求項２または３に記載の計算リソース提供方法。
【請求項５】
前記タスクの計算結果または途中結果の前記ユーザ端末への送信は、前記車群内の車載
端末のうち前記ユーザ端末と通信可能な車載端末を介して行われる、
請求項３または４に記載の計算リソース提供方法。
【請求項６】
前記タスクを実行している車載端末は、前記車両情報に基づいて、前記車群内の他の車載端末が前記タスクの実行に適していると判断された場合には、前記タスクを当該他の車載端末へ移送する、
請求項２から５のいずれか１項に記載の計算リソース提供方法。
【請求項７】
前記実行依頼受信ステップは、
前記車群リソース情報を前記ユーザ端末へ送信するステップと、
前記車群リソース情報に基づいて前記ユーザ端末から送信されるタスクの実行依頼を受け付けるステップと、
を含む、請求項１から６のいずれか１項に記載の計算リソース提供方法。
【請求項８】
前記実行依頼受信ステップは、
前記ユーザ端末から、タスクの実行に関する要求を取得するステップと、
前記車群リソース情報に基づいて、前記ユーザ端末からのタスクの実行依頼を受け付けるか否かを判断するステップと、
を含む、請求項１から６のいずれか１項に記載の計算リソース提供方法。
【請求項９】
前記車群形成管理ステップにおいて、各車載端末は、自車両と同じ方向に走行し、自車両よりも後方に位置し、かつ、直接または間接的に通信可能な車両が車群に含まれると判断する、
請求項１から８のいずれか１項に記載の計算リソース提供方法。
【請求項１０】
前記通知ステップにおいては、各車載端末は、自車両が車群に属すると判断する車両および自車両に関する車両情報を送信し、
自車両の前方に車両が検知された場合は、前方に車両が検知された旨を前記車両情報に含めて送信し、
前記車群形成管理ステップでは、前方に車両が検知された旨も自車両に関する情報も含まれない車両情報、前方に車両が検知された旨と自車両に関する情報が含まれる車両情報、および、前記車群に属する車両の車両情報を用いて、車群を形成および管理する、
請求項９に記載の計算リソース提供方法。
【請求項１１】
車群内でメッセージを転送する転送ステップをさらに有し、当該転送ステップでは、前記メッセージの送信元が前記車群に属する車両であり、かつ宛先が前記車群に属さない車両である場合、または、前記メッセージの送信元が前記車群に属さない車両であり、かつ宛先が前記車群に属する車両である場合に、前記メッセージの転送を行い、そうでない場合は、前記メッセージの転送を行わない、
請求項１０に記載の計算リソース提供方法。
【請求項１２】
ユーザ端末からタスクの実行依頼を受け付けて実行する車両システムにおける車載端末であって、
車両が提供可能な計算リソースに関する情報を少なくとも含む情報である車両情報を送信する送信手段と、
自車両の車両情報および他の車両から送信される車両情報に基づいて、車群を形成および管理する車群形成管理手段と、
前記車群が前記ユーザ端末と通信可能な時間と当該時間内において提供可能な計算リソースとに関する情報である車群リソース情報を格納する車群リソース情報格納手段と、
前記車群リソース情報を前記ユーザ端末に通知して前記ユーザ端末からタスクの実行依
頼を受け付けるか、または、前記ユーザ端末からタスクの実行に関する要件を取得して前記車群リソース情報に基づいて前記ユーザ端末からのタスクの実行依頼を受け付けるか否かを決定する、実行依頼受信手段と、
を含む、車載端末。
【請求項１３】
請求項１から１１のいずれか１項に記載の計算リソース提供方法を車載端末に実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ユーザ端末からタスクの実行依頼を受け付けて実行する計算リソース提供方法およびシステムに関する。
関連する。
【背景技術】
【０００２】
近年、車両には高機能な計算処理装置、記憶装置、無線通信装置、センサが搭載されている。このような計算リソースを他車両や車両以外の装置に提供することで、車両ネットワークシステムはＩＣＴ基盤（巨大なＣＰＵやストレージ等）として活用できる。
【０００３】
このような車両ネットワークに対してスマートフォンなどの携帯情報端末（ユーザ端末）から計算タスクの実行を依頼することが想定される（非特許文献１）。計算タスクの実行を車両ネットワークに依頼することで、携帯情報端末は、消費電力の削減や、より迅速な計算結果の取得といった効果が得られる。
【０００４】
車両は高速で移動するため、車両とユーザ端末とが通信できる期間は比較的短い。非特許文献２は、ユーザ端末との通信可能期間が限られていることを考慮して、以下に示す処理を行うことを提案する。すなわち、タスクの実行依頼を受け付けた端末は、ユーザ端末の通信範囲内に存在する間のみタスクを実行し、範囲外に移動する際には、適切な（タスクを実行可能であり、ユーザ端末と通信可能な）他端末に計算タスクを渡す。この際、適切な他端末が存在しない場合には、ユーザ端末に途中結果を返す。
【先行技術文献】
【非特許文献】
【０００５】
【非特許文献１】RIVA, Oriana, et al. Context-aware migratory services in ad hoc networks. Mobile Computing, IEEE Transactions on, 2007, 6.12: 1313-1328.
【非特許文献２】HANDOREAN, Radu, et al. Context aware session management for services in ad hoc networks. In: Services Computing, 2005 IEEE International Conference on. IEEE, 2005. p. 113-120.
【発明の概要】
【発明が解決しようとする課題】
【０００６】
非特許文献２では、計算タスクを依頼する情報処理端末を決定する際に、それぞれの情報処理端末の情報のみを考慮して決定する。すなわち、計算タスクの委託端末を決定する際に、委託端末がユーザ端末の通信範囲外に移動する際のタスクの移行先を考慮することはできない。委託端末が移行先を発見できない場合には、ユーザ端末に途中結果とタスクが戻される。そのため、情報処理端末が断続的にユーザ端末周辺に出現する場合には、その都度、タスク委託処理とそのための通信処理が発生し、ユーザ端末が自身でそのタスクを実行するよりも消費電力が増えたりタスク完了時刻が遅くなったりしてしまう。このように、非特許文献２では、ユーザ端末は、計算タスクを他端末に委託すべきか自ら実行すべきかを適切に判断することができない。
【０００７】
本発明は、ユーザ端末が車両に対して計算タスクを委託することが有利であるかどうかを適切に判断可能な計算リソース提供方法およびシステムを提供することを目的とする。
【課題を解決するための手段】
【０００８】
上記の目的を達成するために、本発明の第一の態様では、複数の車載端末から構成され
る車両システムにおいて、直接または間接的に通信可能な複数の車両からなる車群を形成し、車群として提供可能な計算リソース（計算資源）に関する情報をユーザ端末に提供する。これにより、ユーザ端末は、中長期的に利用可能な計算リソースが把握でき、計算タスクを委託すべきかどうかを適切に判断できる。
【０００９】
より具体的には、本発明の一態様は、複数の車載端末から構成され、ユーザ端末からタスクの実行依頼を受け付けて実行する車両システムにおける計算リソース提供方法であって、通知ステップと、車群形成管理ステップと、車群リソース情報生成ステップと、実行依頼受信ステップと、を含む。
【００１０】
通知ステップでは、車載端末の間で、それぞれの車両が提供可能なリソースに関する情報を含む情報（車両情報）を交換する。各車載端末が送信する車両情報は、少なくとも自車両が提供可能なリソースに関する情報を含み、自車両が把握している車群内の車両が提供可能なリソースに関する情報も含むことが望ましい。計算リソースに関する情報は、例えば、車載端末が提供可能な機能や、演算速度、利用可能な記憶容量が該当する。車両情報は、上記の情報以外に、車両の識別子、位置、移動速度、目的地、走行予定経路などの情報を含むことも好ましい。
【００１１】
車群形成管理ステップでは、各車載端末が、自車両が把握している車両情報および他の車両から送信される車両情報に基づいて、車群の形成および管理を行う。車群は、自車両と直接あるいは他の車両を介して間接的に（マルチホップで）通信可能な車両の少なくとも一部から形成されることが望ましい。車群は、直接または間接的に通信可能な全ての車両から形成されてもよいし、その一部、例えば自車両よりも後方の車両から形成されてもよい。車群の形成にあたっては、車両情報に含まれる任意の情報を考慮に入れることができる。例えば、車両情報に目的地や移動速度が含まれる場合には、自車両と通信可能な期間を予測してその期間が所定の長さ以上の車両を、車群に含めるようにしてもよい。車群形成管理ステップでは、さらに、車群を構成する各車両についての情報を取得することも好ましい。例えば、車両情報に基づいて、各車両の位置や、車群全体の移動速度、車群内の最後方車両の識別子などを車群に関する情報として取得することができる。
【００１２】
車群リソース情報生成ステップでは、車群リソース情報を生成する。車群リソース情報には、車群がユーザ端末と通信可能な時間と、車群が当該時間内において提供可能な計算リソースとに関する情報を含む。なお、車群がユーザ端末と通信可能な時間は、車群内のいずれかの車両がユーザ端末と通信可能な時間として表されればよく、個々の車両がユーザ端末と通信可能な時間は必ずしも求めなくてもよい。また、車群が提供可能な計算リソースについても、車群が全体として提供可能な計算リソースとして表されればよい。提供可能な計算リソースに関する情報は、例えば、対応可能なタスクの種類に関する情報、単位時間あたりの計算量、利用可能な記憶容量を含む。
【００１３】
実行依頼受信ステップでは、車載端末が、車群リソース情報と合致するタスクの実行依頼をユーザ端末から受け付ける。車群リソース情報と合致するタスクというのは、車両システムでの実行が適切であると車群リソース情報に基づいて判断されるタスクを意味する。この判断を行う主体は、ユーザ端末であってもよいし、車載端末であってもよい。例えば、車載端末が上記車群リソース情報をユーザ端末に送信し、ユーザ端末が車群リソース情報に基づいてタスクの車両システムへの実行依頼が適切であるか判断して、実行依頼が適切なタスクを車載端末に送信し、車載端末がユーザ端末から当該実行依頼を取得することができる。あるいは、ユーザ端末が車載端末に対してタスクの実行に必要とされる要件を通知し、車載端末が車群リソース情報に基づいて当該要件を満足するかを判断して、満足する場合にタスクの実行依頼をユーザ端末から受け付けることもできる。
【００１４】
このような構成によれば、ユーザ端末は、個々の車載端末ではなく車群が全体として提供可能な計算リソースを把握できる。すなわち、ユーザ端末は、中長期的に利用可能な計算リソースを考慮して、自装置でタスクを実行すべきか、車群（車載端末）に実行を依頼するべきかを適切に判断することができるようになる。これにより、車載端末への無駄な接続を減らし、ユーザ端末における不要な負荷の増加を避けることができる。
【００１５】
本発明における計算リソース提供方法は、さらに以下の決定ステップ、移送ステップ、実行ステップを含むことができる。
【００１６】
決定ステップでは、ユーザ端末からタスクの実行依頼を受け付けた車載端末が、車群リソース情報に基づいて、タスクを実行する車載端末を決定する。この決定は、車群内の車載端末の中から、当該タスクを実行可能な１または複数台の車載端末を選択することにより行える。決定に際して、処理が最も早く終了できる車載端末を選択したり、要求された期限までに処理を終了できる車載端末を選択したりするなど、その他の要素を考慮することも好ましい。依頼されたタスクが分割可能であれば、分割して複数の車載端末に実行させてもよい。また、同一のタスクを複数の車載端末に実行させてもよい。
【００１７】
移送ステップでは、ユーザ端末からタスクの実行依頼を受け付けた車載端末が、決定ステップにおいて決定された車載端末に対して当該タスクを移送する。移送先の車載端末と直接の通信ができない場合には、車両システム内での中継（マルチホップ通信）が行われる。
【００１８】
実行ステップでは、タスクを移送された車載端末が当該タスクを実行する。タスクの実行が完了したら、当該タスクを実行していた車載端末が、計算結果をユーザ端末に送信する。計算結果のユーザ端末への送信は、直接の通信によって行われてもよいし、車群内の他の車載端末を介して行われてもよい。計算結果のユーザ端末への送信は、タスク完了後すぐに行われることが好ましいが、所定時間後に行われてもよい。例えば、タスクを実行している車載端末がタスクの実行完了時にはユーザ端末と直接通信可能ではないが、その後にユーザ端末と直接通信可能になると予測される場合には、ユーザ端末と直接通信可能になるのを待ってから、ユーザ端末に計算結果を送信してもよい。
【００１９】
このような構成によれば、ユーザ端末は車群全体を一つのエンティティとして捉えることができ、車群を構成する個々の車載端末についての情報を把握する必要がなくなる。すなわち、車載端末間でのタスクの受け渡しの際に、ユーザ端末が関与する必要がなくなるので、ユーザ端末が行う処理量や電力消費量を減らすことができる。
【００２０】
本発明における計算リソース提供方法は、ユーザ端末からタスクの実行依頼を受け付けた後に、ユーザ端末と車群とが継続して通信可能な時間に関する情報を定期的に算出するステップと、上記通信可能な時間内にタスクが完了しないと予測される場合は、前記タスクを実行している車載端末がタスクの途中結果をユーザ端末に直接または間接的に送信するステップと、をさらに含むことも好ましい。通信可能な時間に関する情報の算出および時間内にタスクが完了するか否かの予測は、タスクを実行している車載端末が行ってもよいし、車群内の他の車載端末が行ってもよい。時間内にタスクが完了するか否かの予測は、例えば、残りの計算量と通信可能時間と単位時間あたりに実行可能な計算量に基づいて行うことができる。あるいは、ユーザ端末と車群の最後方車両の間の距離が所定の閾値以下となった場合に、時間内に処理が完了しないと判断することもできる。この所定の閾値は、固定値であってもよく、車群の移動速度が速いほど小さい値であってもよい。
【００２１】
このような構成によれば、ユーザ端末と車群とが通信可能な間にタスクの実行が完了しなかった場合であっても、その結果（途中結果）をユーザ端末に送信することができる。
【００２２】
本発明において、ユーザ端末から依頼されたタスクは１つの車載端末が行う必要は無く、タスク実行中の車載端末が、実行途中にタスクを他の車載端末に移送してもよい。例えば、タスクを実行している車載端末は、前記車両情報に基づいて、前記車群内の他の車載端末が前記タスクの実行に適していると判断された場合には、前記タスクを当該他の車載端末へ移送することができる。適切さの判断基準は、適宜定めることができる。
【００２３】
このような構成によれば、タスクを実行に適した車載端末が変化した場合に、タスクを移送して当該車載端末にタスクを実行させることができる。すなわち、常に車群内の適切な車載端末がタスクを実行するようにできる。
【００２４】
また、本発明の車群形成管理ステップにおいて、各車載端末は、自車両と同じ方向に走行し、自車両よりも後方に位置し、かつ、直接または間接的に通信可能な車両が車群に含まれると判断する、ことができる。この場合、それぞれの車載端末が把握している車群は異なる車両から構成されることになる。
【００２５】
この場合、他車両が前方に位置するか後方に位置するかの判断を、位置情報に基づいて行うこともできるが、次のようにして行うこともできる。すなわち、通知ステップにおいては、各車載端末は、自車両が車群に属すると判断する車両および自車両に関する情報を前記車両情報として送信する。また、自車両の前方に車両が検知された場合は、前方に車両が検知された旨を前記車両情報に含めて送信する。車群形成管理ステップでは、前方に車両が検知された旨も自車両に関する情報も含まれない車両情報、前方に車両が検知された旨と自車両に関する情報が含まれる車両情報、および、前記車群に属する車両の車両情報を用いて、車群を形成および管理する。このようにすれば、位置情報に基づいて前後関係を判断するよりも簡単な処理によって、車両の前後関係を判断することができる。
【００２６】
本発明において、計算タスクとは、情報処理装置（コンピュータ）において実行可能な任意の処理を意味する。したがって、計算タスクには、数式の演算だけでなく、外部装置からのデータの取得や、外部装置へのデータの出力・送信などの処理も含まれる。また、計算タスクは、単にタスクとも称される。
【００２７】
本発明において、計算タスクの実行依頼は、どのような態様によって実施されてもよい。例えば、実行依頼は、バイナリ、実行可能なスクリプト言語を含むソースコード、中間コード（バイトコードとも呼ばれる）、実行コマンドあるいは関数名、または一般的な作業指示書とすることができ、これにデータ、パラメータ、引数、処理結果などを加えて渡してもよい。
【００２８】
本明細書において、車載端末とは、車両に備え付けられた情報処理装置（コンピュータ）や、車両内部に持ち運ばれた情報処理装置を意味する。情報処理装置は、ＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）などの汎用の演算プロセッサとプログラムを格納した記憶装置の組み合わせ、ＦＰＧＡ（Field-Programmable Gate Array）などのプログラム可能な集積回路（プログラマブルロジックデバイス）、ＡＳＩＣ
（Application Specific Integrated Circuit）などの集積回路、の少なくともいずれか
を含む。
【００２９】
なお、本発明は、上記処理の少なくとも一部を実行する計算リソース提供方法として捉えることもできる。本発明は、上記処理の少なくとも一部を実行する手段を備える計算リソース提供システム、車両システム、あるいは車載端末（車載通信装置）として捉えることができる。また、本発明は、この方法をコンピュータに実行させるためのコンピュータプログラム、あるいはこのコンピュータプログラムを非一時的に記憶したコンピュータ可
読記憶媒体として捉えることもできる。上記手段および処理の各々は可能な限り互いに組み合わせて本発明を構成することができる。
【発明の効果】
【００３０】
本発明によれば、ユーザ端末が車両に対して計算タスクを委託することが有利であるかどうかを適切に判断可能な計算リソース提供方法およびシステムを提供できる。
【図面の簡単な説明】
【００３１】
【図１】図１は、実施形態に係る計算システムのシステム概要図。
【図２】図２Ａは車載端末の装置構成図、図２Ｂは車載端末の機能ブロック図。
【図３】図３Ａはユーザ端末の装置構成図、図３Ｂはユーザ端末の機能ブロック図。
【図４】図４は、実施形態に係る計算システムが実行する全体処理のフローチャート。
【図５】図５は、リソース情報ＤＢの例。
【図６】図６は、リソース情報送信処理のフローチャート。
【図７】図７は、リソース情報受信処理・リソース情報ＤＢ更新処理のフローチャート。
【図８】図８は、安定的な状態の車群における車群形成管理処理を説明する図。
【図９】図９は、２つの車群が合流する際の後方車群における車群形成管理処理を説明する図。
【図１０】図１０は、２つの車群が合流する際の前方車群における車群形成管理処理を説明する図。
【図１１】図１１は、正常ケースにおける動作例に係るタスクの実行依頼から計算結果までの処理の流れを説明する図。
【図１２】図１２は、正常ケースにおける動作例に係るシーケンス図。
【図１３】図１３は、例外ケースにおける動作例に係るタスクの実行依頼から計算結果までの処理の流れを説明する図。
【図１４】図１４は、例外ケースにおける動作例に係るシーケンス図。
【図１５】図１５は、ユーザ端末の位置情報の共有方法を説明する図。
【図１６】図１６は、車群内でのメッセージ転送処理のフローチャート。
【発明を実施するための形態】
【００３２】
以下では説明の簡略化のために、車載端末と車両とを区別せずに相互に交換可能な意味として用いる。例えば、車両に搭載された車載端末が処理を行うことを、車両が処理を行うと表現することがある。あるいは、車両の位置や移動経路のことを、車載端末の位置や移動経路と表現することもある。また、車両と当該車両に搭載された車載端末に対して、同一の参照符号を用いることもある。
【００３３】
＜概要＞
図１は、本実施形態に係る計算システムのシステム概要を説明する図である。本実施形態に係る計算システムは、ユーザが利用するユーザ端末２００および車両に搭載された複数の車載端末１００から構成され、ユーザ端末２００が車載端末１００に対して計算タスクの実行を委託する。
【００３４】
本実施形態では、複数の車載端末１００が車群１０を形成し、ユーザ端末２００からは車群１０が１つの計算リソースとして把握できるようにする。例えば、ユーザ端末２００が車群１０内のある車両にタスクを実行依頼した後の車群１０内での計算タスクの移送には、ユーザ端末２００が関与する必要がないように構成する。ユーザ端末から委託された計算タスクは、車群１０内のいずれかの車載端末１００（複数であってもよい）によって実行され、いずれかの車載端末１００からユーザ端末に計算結果が送信される。
【００３５】
このように、ユーザ端末２００にとって、車群１０が１つの計算リソースとして認識できるように、車群１０を構成する車両１００からは、車群１０が全体としてユーザ端末２００と通信可能な間に提供可能な計算リソースに関する情報を提供する必要がある。車群全体としての計算リソースに関する情報（車群リソース情報と称する）の生成および通知方法については、以下で詳細に説明する。
【００３６】
＜構成＞
図２Ａは、本実施形態における車載端末１００の装置構成を示す図である。車載端末１００は、演算装置１０１、記憶装置１０２、ＧＰＳ装置１０３、入出力装置１０４、無線通信装置１０５、複数のセンサ１０６を含む。
【００３７】
演算装置１０１は、ＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）などのプロセッサを含み、記憶装置１０２に格納されたプログラムを実行することで所定の機能を提供する。記憶装置１０２は、ＲＡＭ（Random Access Memory）などの主記憶装置や半導体メモリ・磁気ディスク・光ディスク・光磁気ディスクなどの補助記憶装置を含む。ＧＰＳ装置１０３は、不図示のＧＰＳ受信機からＧＰＳ衛星信号を受信し、車両１００の位置情報を取得する。入出力装置１０４は、キーボードや種々のポインティングデバイス（マウス、タッチパッド、タッチパネル、ペンタブレット等）やマイクなどの入力装置、ディスプレイ装置（液晶ディスプレイ・ＣＲＴディスプレイ・プロジェクタ等）や音声出力装置などの出力装置を含む。無線通信装置１０５、他の車両１００およびユーザ端末２００との間で通信可能な無線通信装置である。無線通信の通信方式は、任意であってよい。また、車両間での通信とユーザ端末との通信は、同一方式であってもよいし、それぞれ異なる方式であってもよい。センサ１０６は、車両１００の内部および外部に関する情報を取得するためのセンサであり、例えば、車外カメラ（可視光カメラや赤外カメラ、ステレオカメラも含む）、測距レーダー（ミリ波レーダー、超音波レーダー）、車速センサ、加速度センサなどが含まれる。
【００３８】
図２Ｂは、車載端末１００の機能構成を示す機能ブロック図である。車両１００の演算装置１０１が記憶装置１０２に格納されているプログラムを実行することで、以下の機能が実現される。すなわち、車載端末１００は、車両情報取得部１１、リソース情報受信部１２、リソース情報更新部１３、リソース情報ＤＢ１４、リソース情報送信部１５、タスク実行依頼受信部１６、タスク実行制御部１７、タスク移送部１８、タスク実行部１９、実行結果送信部２０等の機能を提供する。これら各機能の詳細について、後ほど処理内容を説明する際にあわせて説明する。
【００３９】
図３Ａは、本実施形態におけるユーザ端末２００の装置構成を示す図である。ユーザ端末２００は、演算装置２０１、記憶装置２０２、ＧＰＳ装置２０３、入出力装置２０４、無線通信装置２０５を含む。各要素は基本的に車載端末１００におけるものと同様であるため、詳しい説明は省略する。
【００４０】
図３Ｂは、ユーザ端末２００の機能構成を示す機能ブロック図である。ユーザ端末２００の演算装置２０１が記憶装置２０２に格納されているプログラムを実行することで、以下の機能が実現される。すなわち、ユーザ端末２００は、リソース情報受信部２１、タスク実行制御部２２、タスク実行依頼送信部２３、位置情報送信部２４、実行結果受信部２５、タスク実行部２６等の機能を提供する。これら各機能の詳細について、後ほど処理内容を説明する際にあわせて説明する。
【００４１】
＜処理内容＞
［全体処理］
図４は、本実施形態に係る計算システムが実行する全体処理の概要を示すフローチャートである。このフローチャートでは、ユーザ端末２００と車両システムが実行する処理を記載している。車両システムが実行すると示されている処理は、車両システム内の少なくとも一部の車両１００が独自に行う処理、車両システム内の複数の車両１００が協調して行う処理が含まれる。
【００４２】
ステップＳ４０１では、各車両の間でリソース情報を交換して、車群の形成および維持管理を行う。本実施形態では、各車両が、自車両および同一の車群に含まれる車両が提供可能なリソースに関する情報を、定期的にブロードキャスト送信する。本実施形態では、各車両は、自車両よりも後方に位置し、直接通信可能または中継車両を介して通信可能な車両が、自車両と同一の車群に含まれると判断して車群を形成する。したがって、各車両が把握している車群の構成車両はそれぞれ異なる。本ステップの処理は、図６−図１０を参照して後ほど詳しく説明する。
【００４３】
ステップＳ４０１の処理の結果、リソース情報ＤＢ１４には、車群を構成する車両についての情報が格納される。図５は、リソース情報ＤＢ１４の例を示す図である。図５は、識別ＩＤがＣ００１の車両（以下、車両Ｃ００１のように表現することもある）のリソース情報ＤＢ１４の例である。この例では、車両Ｃ００１が、車両Ａ００１および車両Ｂ００１と車群を形成している場合を示している。
【００４４】
識別ＩＤ５０１には、車群を構成する車両の識別ＩＤが格納される。リソース情報５０２には、各車両が提供可能なリソースに関する情報が格納される。本例では、各車両が提供可能な機能は共通しているが利用可能なメモリ容量が異なることを想定しており、したがって、リソース情報５０２には利用可能なメモリ容量に関する情報が格納されている。ホップ数５０３は、車群の先頭車両からのホップ数を表す。なお、本実施形態では、それぞれの車両が、自車両が車群の先頭車両となるように独自に車群を定義しているので、ホップ数５０３は自車両（リソース情報ＤＢ１４の保有車両）からのホップ数を表すとも捉えられる。距離情報５０４には、各車両とその前方車両との間の距離が格納される。車群の先頭車両には前方車両が存在しないので、先頭車両の距離情報５０４は空欄となる。最後尾車両５０５には、車群の最後尾の車両の識別ＩＤが格納される。
【００４５】
なお、ステップＳ４０１のリソース情報の交換および車群の形成管理処理は、フローチャートでは一度のみ行うように記載されているが、実際には繰り返し実行され、車群に関する情報が最新に保たれる。
【００４６】
ステップＳ４０２では、車両システムが、ユーザ端末２００に対してリソース情報を送信する。具体的には、各車両１００のリソース情報送信部１５が、自車両が把握している車群についてのリソース情報を、ユーザ端末２００が受信可能なように送信（例えばブロードキャスト送信）する。車群についてのリソース情報（車群リソース情報とも称する）には、車群がユーザ端末２００と通信可能な時間や、この通信可能時間内に車群が提供可能な計算リソースに関する情報が含まれる。
【００４７】
ステップＳ４０２において送信される車群リソース情報は、リソース情報送信部１５がリソース情報ＤＢ１４を参照して生成する。車群がユーザ端末と通信可能な時間は、距離情報５０４に基づいて求められる自車両（車群先頭車両）から車群最後方車両までの距離に無線通信可能距離を加えた距離と、車群の平均移動速度とを用いて決定できる。車群が提供可能な計算リソースに関する情報は、リソース情報５０２から決定できる。
【００４８】
ステップＳ４０３では、ユーザ端末２００のリソース情報受信部２１が、車両システムから送信される車群リソース情報を受信し、この情報に基づいて計算タスクを車両システ
ムに依頼すべきかどうかをタスク実行制御部２２が判断する。この判断基準は適宜決定すればよい。例えば、車両システムと通信可能な間に車両システムがタスクの実行（および結果の送信）を完了できると判断できれば、車両システムに計算タスクの実行を依頼すると判断することができる。計算タスクを車両システムに委託する場合はステップＳ４０４に進み、そうでない場合にはユーザ端末２００（タスク実行部２６）においてタスクを実行する。
【００４９】
ステップＳ４０４では、ユーザ端末２００のタスク実行依頼送信部２３が、車両システムに対して計算タスクの実行依頼を送信する。計算タスクの実行依頼は、例えば、計算タスクのソースコードを含む。また、ソースコード以外に、中間コードやバイナリによって計算タスクが表されてもよい。
【００５０】
後述するように、ユーザ端末２００は、計算タスクを車両システムに依頼する際に、車両システムからこの計算タスクのタスクＩＤを取得する。ユーザ端末２００は、タスクの実行依頼（Ｓ４０４）後からタスク結果の受信（Ｓ４１０）までの間、位置情報送信部２４によって自装置の位置情報およびタスクＩＤを定期的に送信する。この位置情報は、車両システムにおいて、ユーザ端末２００と車両システムとが通信可能な時間を計算するために用いられる。
【００５１】
ステップＳ４０５において、車両システムがユーザ端末２００から計算タスクの実行依頼を受信する。具体的には、車両システム内の車両であってユーザ端末２００と直接通信が可能な車両１００がこの実行依頼を受信する。この車両１００は、タスク実行依頼受信部１６によってユーザ端末２００からのタスク実行依頼を受信し、タスク実行制御部１７によって依頼タスクを実行する車両を決定し、タスク移送部１８によって当該車両に対して依頼タスクを送信する。タスク実行車両の決定は、車群リソース情報ＤＢ１４に基づいて行われる。
【００５２】
ステップＳ４０６において、ステップＳ４０５において計算タスクを受信した車両が、タスク実行部１９によってこのタスクを実行する。なお、計算タスクの実行中に、タスク実行制御部１７によって他の車両の方がタスクの実行により適していると判断された場合には、タスク移送部１８によって当該車両に対してタスクの移送を行ってもよい（ステップＳ４０７）。
【００５３】
ステップＳ４０８では、計算タスクの実行が完了したか、または、ユーザ端末２００と車群との通信が近いうちに切断すると予測されるか、がタスク実行制御部１７によって判断される。計算タスクの実行が完了しておらず、ユーザ端末２００との通信も維持されると判断される場合には、ステップＳ４０６に戻る。一方、計算タスクの実行が完了したか、または、ユーザ端末２００と車群との通信が近いうちに切断すると予測された場合には、ステップＳ４０９に進む。
【００５４】
ステップＳ４０９では、車両システムからユーザ端末２００に対して計算結果または途中結果が送信される。具体的には、ユーザ端末２００と直接通信可能な車両１００が実行結果送信部２０によって決定され、当該車両１００を介して計算結果または途中結果がユーザ端末２００に送信される。ステップＳ４１０では、ユーザ端末２００の実行結果受信部２５が車両システムからこの計算結果または途中結果を受信する。
【００５５】
上述のステップＳ４０２〜Ｓ４１０の処理は、図１１−図１６を参照して後ほどより詳しく説明する。
【００５６】
［リソース情報（車両情報）交換および車群形成管理処理］
ステップＳ４０１における車両情報交換及び車群形成管理処理について、より詳細に説明する。図６は、リソース情報を送信する処理の流れを示すフローチャートである。図７は、リソース情報を受信し、受信したリソース情報に基づいて車群の形成管理（リソース情報ＤＢ１４の更新）を行う処理の流れを示すフローチャートである。
【００５７】
図６に示すリソース情報送信処理は、各車両において定期的に（例えば、１００ミリ秒おき）に実行される。ステップＳ６０１では、車両情報取得部１１が、センサ群１０６からセンサ情報を取得する。取得するセンサ情報には、前方のカメラ画像、前方車両（物体）との距離、位置、速度などが含まれる。フローチャートには明示していないが、センサ情報が取得されたら、リソース情報更新部１３が、リソース情報ＤＢ１４内の自車両に関する情報を更新する。
【００５８】
ステップＳ６０２では、リソース情報送信部１５が、リソース情報ＤＢ１４を参照して車両向けのリソース情報通知パケットを生成する。本実施形態では、リソース情報ＤＢ１４に含まれている車群内の各車両についての車両情報を、リソース情報通知パケットに含める。また、リソース情報通知パケットには、前方に車両が新たに検出されたかどうかを示す新規検出フラグ（詳細は後述）が含まれる。新規検出フラグの初期値はオフである。また、リソース情報通知パケットには、図５で示した以外の情報を含めることも好ましい。例えば、車両の位置、移動速度、目的地、走行予定経路などの情報を含めることも好ましい。
【００５９】
ステップＳ６０３では、リソース情報送信部１５が、前方に新たに車両が検出されたか否かをセンサ情報等に基づいて判断する。前方車両の有無は、カメラ画像や距離センサなどから判断することができる。それまで前方車両が存在しないと判断されている状態で前方車両が検出された場合に、前方車両が新たに検出されたと判断できる。
【００６０】
前方車両が新たに検出された場合にはステップＳ６０４に進み、リソース情報通知パケットに含まれる新規検出フラグをオンに設定する。前方車両が新たに検出されていない場合には、新規検出フラグはオフのままである。
【００６１】
ステップＳ６０５では、リソース情報送信部１５が、生成されたリソース情報通知パケットを無線通信装置１０５を介して他の車両向けに送信する。本実施形態では、リソース情報通知パケットは、車車間通信用のチャネルでブロードキャスト送信されるものとする。
【００６２】
以上の、他車両宛のリソース情報送信処理（および送信されたリソース情報通知パケットを受信する処理）が、本発明における、車両情報を交換するステップに該当する。
【００６３】
図７に示すリソース情報受信処理および車群形成管理処理は、各車両において、リソース情報パケットを受信する度に実行される。ただし、車群形成管理処理は、送信間隔と同じ間隔で行われてもよい。
【００６４】
ステップＳ７０１では、リソース情報受信部１２が、他の車両からのリソース情報通知パケットを受信する。以下の、ステップＳ７０２〜Ｓ７０４では、受信したリソース情報通知パケットが同一車群内の車両（すなわち、後方の車両）からの通知パケットであるか否かを、リソース情報更新部１３が判断する。なお、以下の処理は、自車両と同一方向の走行している車両からの通知パケットを対象にして行い、自車両と反対方向に走行している車両からの通知パケットは処理の対象としない（無視する）。
【００６５】
ステップＳ７０２では、リソース情報更新部１３が、通知パケット内に自車両に関する
情報が含まれているか、すなわち、自車両の識別ＩＤが含まれているか否かを判断する。自車両に関する情報が含まれている場合（Ｓ７０２−ＹＥＳ）には、通知パケットの送信元車両は前方の車両であると判断できるので、この通知パケットに基づくリソース情報ＤＢ１４の更新は行わない（Ｓ７０６）。
【００６６】
ステップＳ７０３では、リソース情報更新部１３が、通知パケット内の新規検出フラグがオンであるか否かを判断する。通知パケット内に自車両に関する情報が含まれず、新規検出フラグがオンである場合（Ｓ７０２−ＮＯかつＳ７０３−ＹＥＳ）には、後方の車群からの通知であると判断できるので、リソース情報更新部１３が、この通知パケットに基づいてリソース情報ＤＢ１４を更新する（Ｓ７０５）。通知パケットには、新規車両（リソース情報ＤＢ１４に登録されていない車両）に関する情報が含まれるので、これらの車両に関する情報がリソース情報ＤＢ１４に登録される。
【００６７】
ステップＳ７０４では、リソース情報更新部１３が、通知パケット内に同一車群内の車両（リソース情報ＤＢ１４に登録されている車両）に関する情報が含まれているか否かを判断する。新規検出フラグがオフにかかわらず、通知パケット内に自車両に関する情報が含まれずかつ同一車群の車両に関する情報が含まれていない場合（Ｓ７０２−ＮＯかつＳ７０３−ＮＯかつＳ７０４−ＮＯ）は、前方車群内の車両からの通知であると判断できるので、リソース情報更新部１３はこの通知パケットに基づくリソース情報ＤＢ１４の更新は行わない（Ｓ７０６）。逆に、通知パケット内に同一車群内の車両に関する情報が含まれる場合（Ｓ７０２−ＮＯかつＳ７０３−ＮＯかつＳ７０４−ＹＥＳ）は、同一車群内の車両（後方車両）からの通知であると判断できるので、リソース情報更新部１３は、この通知パケットに基づいてリソース情報ＤＢ１４を更新する（Ｓ７０５）。
【００６８】
以上の、他車両からのリソース情報通知パケットに基づくリソース情報ＤＢ１４の更新処理が、本発明における車群形成管理ステップに該当する。
【００６９】
上記のリソース情報の交換処理および車群形成管理処理を、具体的な動作例を示す図８〜図１０を参照してさらに説明する。
【００７０】
図８は、３台の車両Ａ００１，Ｂ００１，Ｃ００１からなる車群の、定常状態における処理を説明する図である。符号８０１，８０２，８０３は、それぞれ車両Ａ００１，Ｂ００１，Ｃ００１のリソース情報ＤＢ１４の内容である。各車両は、自車両と自車両よりも後方の車両から車群が形成されると判断する。したがって、車両Ａ００１は単独の車群であると判断し、車両Ｂ００１は車両Ａ００１，Ｂ００１から車群が形成されると判断し、車両Ｃ００１は車両Ａ００１，Ｂ００１，Ｃ００１から車群が形成されると判断している。
【００７１】
符号８０４は、車両Ｂ００１が送信するリソース情報通知パケットの内容である。この通知パケットは、車両Ｂ００１の車群リソース情報ＤＢ１４の内容８０２に基づいて生成される。
【００７２】
車両Ａ００１は、車両Ｂ００１から通知パケット８０４が前方車両からの通知であると判断でき、この通知パケット８０４に基づくリソース情報ＤＢ１４の更新は行わない。車両Ｂ００１が車両Ａ００１の前方車両であることは、この通知パケットに自車両の識別ＩＤが含まれる（Ｓ７０２−ＹＥＳ）ことから判断できる。
【００７３】
車両Ｃ００１は、車両Ｂ００１からの通知パケットが後方車両の通知であると判断でき、この通知パケット８０４に基づくリソース情報ＤＢ１４の更新を行う。車両Ｂ００１が車両Ｃ００１の後方車両であることは、この通知パケットに自車両の識別ＩＤが含まれず
（Ｓ７０２−ＮＯ）、新規検出フラグがオフであり（Ｓ７０３−ＮＯ）、かつ、同一車群内の車両（車両Ａ００１，Ｂ００１，Ｃ００１のいずれか）に関する情報が含まれる（Ｓ７０４−ＹＥＳ）ことから判断できる。
【００７４】
図９は、３台の車両Ａ００１，Ｂ００１，Ｃ００１からなる車群ＧＢが、前方の車群ＧＦ（最後尾車両が車両Ｄ００１）に追いついた状況での、後方車群ＧＢにおける処理を説明する図である。符号９０１，９０２はそれぞれ車両Ｃ００１，Ｄ００１のリソース情報通知パケットの内容である（リソース情報ＤＢ１４の内容ともいえる）。
【００７５】
車両Ｃ００１は、前方カメラやレーダーなどから前方に新規の車両を検出する（Ｓ６０３−ＹＥＳ）ので、リソース情報通知パケット９０１において新規検出フラグがオンに設定される。車両Ｃ００１からの通知パケット９０１を受け取った車両Ｂ００１，Ｃ００１は、通知パケット９０１に自車両の識別ＩＤが含まれる（Ｓ７０２−ＹＥＳ）ので、通知パケット９０１に基づくリソース情報ＤＢ１４の更新は行わない。
【００７６】
車両Ｄ００１からの通知パケット９０２を受け取った車両Ｃ００１は、通知パケット９０２に自車両の識別ＩＤは含まれない（Ｓ７０２−ＮＯ）が、同一車群内の車両に関する情報が含まれない（Ｓ７０４−ＮＯ）ことから、車両Ｄ００１が前方車両であると判断でき、通知パケット９０２に基づくリソース情報ＤＢ１４の更新は行わない。
【００７７】
図１０は、後方の車群ＧＢが、３台の車両Ｄ００１，Ｅ００１，Ｆ００１からなる前方の車群ＧＦに追いついた状況での、前方車群ＧＦにおける処理を説明する図である。符号１００１，１００２，１００３はそれぞれ車両Ｃ００１，Ｄ００１，Ｅ００１のリソース情報通知パケットの内容である（リソース情報ＤＢ１４の内容ともいえる）。
【００７８】
車両Ｄ００１は、車両Ｃ００１から新規検出フラグがオンに設定された通知パケット１００１を受信する。通知パケット１００１には、自車両の識別ＩＤが含まれず（Ｓ７０２−ＮＯ）、かつ、新規検出フラグがオンである（Ｓ７０３−ＹＥＳ）ことから、この通知が後方車両からの新規検出を通知するものであると判断できる。したがって、車両Ｄ００１は、通知パケット１００１に基づいて、リソース情報ＤＢ１４の更新処理を行う。更新によって、車両Ｄ００１のリソース情報ＤＢ１４は、車両Ｄ００１に関する情報のみを含む状態（図９の符号９０２）から、通知パケット１００１中の車両Ａ００１，Ｂ００１，Ｃ００１をさらに含む状態（図１０の符号１００２）となる。
【００７９】
車両Ｄ００１のリソース情報ＤＢ１４の更新後は、車両Ｄ００１はリソース情報通知パケット１００２を周囲の車両に送信する。この通知パケット１００２を受信した車両Ｅ００１は、通知パケット１００２に、自車両の識別ＩＤが含まれず（Ｓ７０２−ＮＯ）、かつ、同一車群内の車両に関する情報（車両Ｄ００１，Ｅ００１，Ｆ００１のいずれか）が含まれる（Ｓ７０４−ＹＥＳ）ことから、同一車群内の後方車両からの通知であると判断できる。したがって、車両Ｅ００１は、通知パケット１００２に基づいて、リソース情報ＤＢ１４の更新処理を行う。更新によって、車両Ｅ００１のリソース情報ＤＢ１４は、車両Ｄ００１およびＥ００１に関する情報のみを含む状態から、通知パケット１００２中の車両Ａ００１，Ｂ００１，Ｃ００１をさらに含む状態（図１０の符号１００３）となる。
【００８０】
このように、車群ＧＦの最後尾車両Ｄ００１が別の車群ＧＢと通信可能になると、前方車群ＧＦ内の各車両のリソース情報ＤＢ１４が順次更新される。これにより、車群ＧＦと車群ＧＢの合流が行える。
【００８１】
［タスクの実行依頼受信処理〜実行結果送信処理］
以下、ステップＳ４０２からＳ４１０までの処理について、より詳細に説明する。
【００８２】
まず、図１１および図１２を参照して、タスクの実行をユーザ端末との通信可能時間内に完了できる正常ケースの動作例について説明する。図１１Ａは、ユーザ端末からタスクの実行依頼を受け付けて、タスク実行車両にタスクを送信するまでの処理を説明する図である。図１１Ｂは、タスク実行車両がタスクの実行結果をユーザ端末に送信するまでの処理を説明する図である。図１２は、正常ケースにおける動作の流れを示すシーケンス図である。
【００８３】
まず、車両システム内の各車両は、車両間で車両情報を交換し（Ｓ１２０２）、この車両情報に基づいてリソース情報ＤＢ１４を更新することで、車群内の車両に関する情報を最新に保っている。そして、ユーザ端末ＵＴと通信可能な車両Ａが、車群リソース情報をユーザ端末ＵＴに送信する（Ｓ１２０４）。車群リソース情報は、リソース情報ＤＢ１４に基づいて生成され、車群がユーザ端末ＵＴと通信可能な時間、この通信可能時間内に車群が提供できる計算リソースに関する情報が含まれる。本実施形態では、車群内の各車両が定期的に車群リソース情報をブロードキャストするが、ユーザ端末ＵＴとの接続が完了した場合やユーザ端末ＵＴから要求があった場合に車群リソース情報を送信するようにしてもよい。
【００８４】
車群リソース情報を受信したユーザ端末ＵＴは、実行を予定しているタスクを車群に依頼するべきか否かを判断する（Ｓ１２０６）。具体的には、そのタスクを通信可能期間内に車群が実行完了できるか否かを判断する。タスクを車群に依頼するべきであると判断した場合は、ユーザ端末ＵＴは、次のようにして車群（車両Ａ）に対してタスクの実行依頼を行う。すなわち、ユーザ端末ＵＴはタスクを実行する旨の要求を車両Ａに対して送信し（Ｓ１２０８）、車両Ａはそれに応答してタスクＩＤをユーザ端末ＵＴに送信する（Ｓ１２１０）。ユーザ端末ＵＴは、タスクＩＤとともに計算タスクを車両Ａに送信する（Ｓ１２１２）。
【００８５】
車両Ａは、ユーザ端末ＵＴからタスクの実行依頼を受信すると、このタスクを車群内のどの車両で実行するのが適切であるかを決定する（Ｓ１２１４）。決定基準は任意であり、例えば、最も早く処理を完了できる車両を選択したり、最も品質の良い処理を行える車両を選択したりすることが考えられる。本例では、車両Ｌがタスク実行車両として選択されたものとして説明を進める。すると、車両Ａは、依頼されたタスクをタスクＩＤとともに車両Ｌに送信（移送）する（Ｓ１２１６）。車両Ａが車両Ｌと直接通信できない場合には、車群内で中継を行ってマルチホップ通信を行う。車両Ｌは、タスクを受け取ると、その実行を開始する（Ｓ１２１８）。
【００８６】
ユーザ端末ＵＴは、車群にタスクの実行を依頼した後、自身の位置情報を定期的に車群に対して送信する（Ｓ１２２０，１２２２）。ユーザ端末ＵＴの位置情報はタスクＩＤと一緒に送信され、どのタスクを依頼したユーザ端末の位置情報であるかが把握可能である。ユーザ端末の位置情報は、車群内の車両のうちユーザ端末ＵＴと通信可能な車両が受信し、車群内の他の車両に送信する。このようにして、ユーザ端末ＵＴの位置情報は、車群内で転送されて、全ての車両が受信する。また、ユーザ端末ＵＴの位置情報は、ステップＳ１２０２において車両間で交換されるリソース情報に含めて送信されても良いし、別のメッセージとして送信されても良い。
【００８７】
図１５は、ユーザ端末ＵＴの位置情報を車群内で共有する処理を説明する図である。ユーザ端末ＵＴから位置情報を受け取った車両（図１５では車両Ｂ，Ｃ）は、ユーザ端末情報通知を送信する。ユーザ端末情報通知には、ユーザ端末ＵＴの位置情報、ユーザ端末ＵＴと直接通信が可能な車両、当該車両の最後尾車両からのホップ数が含まれる。図１５は、車両Ｂ，Ｃの２台の車両がユーザ端末ＵＴと直接通信可能であり、まず、車両Ｂ，Ｃが
それぞれユーザ端末情報１５０１，１５０２を送信する。各車両は、この通知に基づいてユーザ端末情報を更新し、周囲の車両に対して送信する。これにより、車群内の全ての車両でユーザ端末情報を共有できる。図１５の例では、各車両がユーザ端末情報１５０３を保有することになる。
【００８８】
車両Ｌにおけるタスクの実行が完了すると（Ｓ１２２４）、車両Ｌは計算結果をユーザ端末ＵＴに送信する。そのためにまず、車両Ｌは、ユーザ端末ＵＴと直接通信が可能な車両を決定する（Ｓ１２２６）。上述したように、車群内の車両は、車群内の各車両はユーザ端末ＵＴと直接通信な車両を把握しているので、ユーザ端末ＵＴと直接通信可能な車両を介してタスクの計算結果をユーザ端末ＵＴへ送信する（Ｓ１２２８）。
【００８９】
なお、車両Ｌにおけるタスクの実行中に、このタスクがユーザ端末ＵＴと通信可能な間に完了できるかを定期的に確認する処理が行われるが、以下で説明するのでここでは説明を省略した。
【００９０】
次に、図１３および図１４を参照して、タスクの実行をユーザ端末との通信可能時間内に完了できない例外ケースの動作例について説明する。図１３は、タスク実行車両がタスクを受信してから、タスクの途中結果をユーザ端末に送信するまでの処理を説明する図である。図１４は、例外ケースにおける動作の流れを示すシーケンス図である。
【００９１】
ユーザ端末ＵＴが車群にタスクを依頼し、タスク実行車両までタスクが送信される処理、およびタスクの依頼後にユーザ端末ＵＴが位置情報を送信する処理（Ｓ１４０２〜Ｓ１４２２）は、図１２のステップＳ１２０２〜１２２２と同様であるので説明は省略する。
【００９２】
車両Ｌがタスクの依頼を取得し、タスクを実行した後からの処理について説明する。車両Ｌは、タスクの実行と並行して、車群がユーザ端末ＵＴと通信可能な期間の間にタスクの実行を完了できるか否かを、ユーザ端末ＵＴの位置情報に基づいて確認している。具体的には、ユーザ端末の位置情報に基づいて把握できるユーザ端末ＵＴと直接通信可能な車両（図１５）と、車群内の各車両の間隔（図５等の距離情報）から、ユーザ端末ＵＴと直接通信可能な車両と車群最後尾車両との間の距離が分かる。この距離と車群の移動速度から、ユーザ端末ＵＴが車群と通信可能な時間が把握できる。なお、車両間の距離に無線通信距離（電波の到達する距離）を加えたり安全係数を掛けたりといった調整を適宜行うことも好ましい。
【００９３】
タスクの実行完了（より正確には、計算結果のユーザ端末への送信）までに要する時間が、ユーザ端末ＵＴと車群が通信可能な時間以下となった場合（Ｓ１４２４）には、タスクの実行を中断し、途中結果をユーザ端末ＵＴへ送信する。具体的には、ユーザ端末ＵＴと直接通信可能な車両を決定し（Ｓ１４２６）、当該車両を介してタスクの計算結果をユーザ端末ＵＴへ送信する（Ｓ１４２８）。
【００９４】
［メッセージ転送処理］
以下、図１６を参照して車群内でのメッセージ転送処理について説明する。本実施形態では、車群には自車両よりも前方の車両を含めていない。したがって、各車両のリソース情報ＤＢ１４には前方車両に関する情報が存在せず、前方にどのような車両が存在するかを把握していない。しかしながら、車両間でタスクやその計算結果を送信する場合には、前方車両へのメッセージ転送処理が必要となる。本実施形態では、前方車両の存在を把握していなくても車両間で適切にメッセージをルーティングできる処理方法を採用する。
【００９５】
ステップＳ１６０１において、車両がメッセージを受信する。このメッセージには、送信元車両の識別ＩＤと、宛先車両の識別ＩＤが含まれる。宛先ＩＤが自車両の識別ＩＤで
ある場合（Ｓ１６０２−ＹＥＳ）には、メッセージの転送は不要であり、自車両がこのメッセージを処理する（Ｓ１６０３）。具体的には、当該メッセージがタスクの実行依頼であればこのタスクを実行し、ユーザ端末への計算結果の送信メッセージであれば、ユーザ端末宛に送信する。
【００９６】
自車両が宛先ではない場合には、送信元識別ＩＤが車群内の車両であるかの判断（Ｓ１６０４）と、宛先識別ＩＤが車群内の車両であるかの判断（Ｓ１６０５，１６０６）を行う。車群内の車両とは、リソース情報ＤＢ１４に格納されている車両である。本実施形態では、車群内の車両は、自車両よりも後方の車両である。
【００９７】
メッセージの転送が必要となるのは、送信元が前方車両であり宛先が後方車両の場合（Ｓ１６０４−ＮＯかつＳ１６０６−ＹＥＳ）と、送信元が後方車両である宛先が前方車両の場合（Ｓ１６０４−ＹＥＳかつＳ１６０５−ＮＯ）である。したがって、これらの判断結果が得られる場合には、ステップＳ１６０７に進みメッセージを転送する。
【００９８】
逆に、送信元と宛先の両方が前方車両（Ｓ１６０４−ＮＯかつＳ１６０６−ＮＯ）、または、送信元と宛先の両方が後方車両（Ｓ１６０４−ＹＥＳかつＳ１６０６−ＹＥＳ）の場合には、メッセージの転送が不要である。したがって、これらの判断結果が得られる場合には、ステップＳ１６０８に進みメッセージを転送しない。
【００９９】
＜本実施形態の有利な効果＞
本実施形態によれば、ユーザ端末は、車群を１つのまとまった計算リソースとして捉えることができ、車群にタスクの実行を依頼した後は位置情報を定期的に送信する以外に、車群との通信が不要となる。また、車群からの車群リソース情報によって、車群が全体として提供できるリソース情報を把握できるので、ユーザ端末は個々の車両に関する情報を知らなくても、通信可能な間に車群が計算を可能であるか否かを判断できる。また、車両において簡易な処理で車群の形成・管理やリソース情報の管理が行える。
【０１００】
＜変形例＞
上記の説明は、本発明を例示的に説明したものであり、本発明を限定するものではない。本発明は、その技術的思想の範囲内で、種々の変形が可能である。
【０１０１】
［変形例１］
上記の説明では、車群は、各車両とそれよりも後方の車両から構成されるものとして説明した。しかしながら、車群の形成方法は任意であって構わない。例えば、位置の前後関係を問わずに、中継により通信可能な車両から車群を構成するようにしてもよい。また、中継により通信可能な全ての車両を車群に含める必要はなく、互いに通信可能な状態が長く（閾値時間以上）継続すると判断される車両から車群を形成するようにすることも好ましい。通信可能な時間は、例えば、車両の相対速度や走行予定経路などから判断できる。その他にも、過去の履歴データと現在の状況から、今後の車両の挙動を予測して、当該予測に基づいて通信可能な時間を判断することもできる。
【０１０２】
また、前方車両を車群に含める場合には、自車両よりも前方に位置する車両のリソース情報等を把握できるので、自車両よりも前方の車両をタスク実行車両として選択することもできる。また、それぞれの車両が自車両よりも前方に位置するか後方に位置するかを把握可能とし、車群リソース情報をユーザ端末に提供する際には後方車両のリソース情報を提供するようにすれば、本実施形態と同様の処理が実現できる。
【０１０３】
また、前方に位置する車両も把握すれば、車群内でのメッセージの転送処理が容易となる。
【０１０４】
［変形例２］
車群内でタスクを実行する車両は、時間とともに変更しても構わない。上記の動作例の説明では、最初に決定された車両だけがタスクを実行しているが、タスクを受信した後に、その他の車両でタスクを実行する方が適切と判断された場合には、車群内の車両間でタスクを移送しても良い。この判断は、車群内の各車両のリソース情報やユーザ端末との位置関係に基づいて行える。判断基準は任意であって良く、例えば、より高速あるいは高品質な処理が行える車両が現れた場合に、その車両の方が適切であると判断できる。あるいは、ユーザ端末よりも後方に位置することをタスク実行車両の条件として設定し、タスク実行車両がユーザ端末を通り越した場合には、後方の車両にタスクを移送しても良い。
【０１０５】
また、１つのタスクを複数の車両で実行しても構わない。例えば、１つのタスクを複数のサブタスクに分割して、各サブタスクをそれぞれ異なる車両で実行するようにしても良い。これにより、車群における負荷分散および処理の高速化が達成できる。あるいは、１つのタスク（またはサブタスク）を複数の車両で同時に実行してもよい。これにより、より確実に処理結果を得ることができる。
【０１０６】
［変形例３］
車群のリソース情報をユーザ端末へ送信する方法は任意である。ユーザ端末において、車群と通信可能な時間内にどれだけの計算を車群が実行できるかを把握できれば、車群リソース情報の送信方法はどのように行ってもよい。一例として、車両がリソース情報ＤＢに基づいて送信する車両情報をユーザ端末が受信し、この車両情報を解析して上記情報を求めてもよい。
【０１０７】
また、ユーザ端末から車群へのタスクの依頼方法も任意である。上記の説明では、車群からユーザ端末に車群リソース情報を送信して、タスクの実行を車群に依頼するかどうかをユーザ端末で判断している。しかしながら、ユーザ端末がタスクの実行に必要とされる要件を通知し、車群内の車両がこの要件を満たすかどうかを判断してもよい。最終的に、車両によって管理される車群のリソース情報に基づいて、ユーザ端末から車群へのタスクの実行依頼が判断されればよい。
【０１０８】
また、タスクの実行依頼の判断にあたり、必ずしもタスクの全てが実行されることを依頼の条件とする必要はない。例えば、ユーザ端末は、全体の処理のうち所定量以上の計算が実行できると判断される場合には、車群にタスクの実行を依頼するようにしても良い。
【０１０９】
［変形例４］
タスクの計算結果は必ずしも即座にユーザ端末に送信する必要はない。タスク実行車両（計算結果を保有している車両）は、今後ユーザ端末と直接通信可能になると判断される場合は、それまで待ってからユーザ端末に直接計算結果を送信しても構わない。これは、依頼されたタスクにリアルタイム性が要求されない場合に有効である。
【０１１０】
［変形例５］
上記の説明では、車群とユーザ端末との通信が切断されるまでの時間を、最後尾車両までの距離と車群の移動速度に基づいて決定している。しかしながら、より単純に最後尾車両までの距離やホップ数に基づいて決定しても構わない。
【０１１１】
また、ユーザ端末と通信可能な間に計算タスクが完了するかどうかの判定は、必ずしもタスク実行車両が行う必要は無い。車群内のいずれかの車両がこの判定を行い、必要に応じてタスク実行車両に対して、タスクの実行を中断して途中結果をユーザ端末に送信するように指示しても良い。
【０１１２】
同様に、タスク実行車両を切り替えるべきかの判断をタスク実行車両以外の車両が判断しても良い。また、ユーザ端末から依頼されたタスクを車群内のどの車両が実行すべきかの判断を、ユーザ端末から直接依頼を受けた車両以外が判断しても良い。
【０１１３】
また、車群に対して計算タスクを依頼する端末は携帯情報端末などユーザが保持する端末に限られず、周辺の存在する車両の車載端末であっても良い。
【符号の説明】
【０１１４】
１００：車両（車載車載端末）
１１：車両情報取得部  １２：リソース情報受信部  １３：リソース情報更新部
１４：リソース情報ＤＢ  １５：リソース情報送信部  １６：タスク実行依頼受信部
１７：タスク実行制御部  １８：タスク移送部        １９：タスク実行部
２０：実行結果送信部
２００：ユーザ端末
２１：リソース情報受信部  ２２：タスク実行制御部    ２３：タスク実行依頼送信部
２４：位置情報送信部      ２５：実行結果受信部      ２６：タスク実行部
【図１】
0006520693.tif 000002
【図２】
0006520693.tif 000003
【図３】
0006520693.tif 000004
【図４】
0006520693.tif 000005
【図５】
0006520693.tif 000006
【図６】
0006520693.tif 000007
【図７】
0006520693.tif 000008
【図８】
0006520693.tif 000009
【図９】
0006520693.tif 000010
【図１０】
0006520693.tif 000011
【図１１】
0006520693.tif 000012
【図１２】
0006520693.tif 000013
【図１３】
0006520693.tif 000014
【図１４】
0006520693.tif 000015
【図１５】
0006520693.tif 000016
【図１６】
0006520693.tif 000017