複数の車両に搭載される複数の車両装置と、前記車両装置とネットワークを介して接続されるセンタ装置と、によって構成される車両分散処理システムであって、前記センタ装置は、前記車両装置に処理依頼情報を送信することによって、複数の前記車両装置に協力を依頼する協力依頼手段、を具備し、前記車両装置は、自車の走行中に収集されるデータである自車データを記憶する自車データ記憶手段と、前記処理依頼情報を受信すると、自車の計算リソースに依頼処理を割り当てる割り当て手段と、前記計算リソースが、前記自車データ記憶手段に記憶される前記自車データを参照し、前記依頼処理を実行する実行手段と、を具備する車両分散処理システム。前記車両装置は、自車の車両情報を前記センタ装置に通知する通知手段、を具備し、前記センタ装置は、前記車両装置から受信する前記車両情報を記憶する車両情報記憶手段と、前記車両情報記憶手段に記憶される前記車両情報に基づき、協力依頼先の前記車両である協力車両を選定する協力車両選定手段と、を具備する請求項1に記載の車両分散処理システム。前記割り当て手段は、自車のエンジンが停止中又は起動中のいずれであるかを判定し、停止中の場合には、前記計算リソースが前記依頼処理を実行するときの計算時間及び/又は消費電力に基づいて割り当て処理を行い、起動中の場合には、前記計算リソースが実行しているタスクの優先度に基づいて割り当て処理を行う請求項1又は請求項2に記載の車両分散処理システム。前記割り当て手段は、自車のエンジンが起動中の場合には、前記計算リソースが実行しているタスクの優先度に応じて前記タスクの実行/中断状態を変更し、前記タスクが中断状態に変更されることによって空きリソースとなる前記計算リソースに前記依頼処理を割り当てる請求項3に記載の車両分散処理システム。前記車両情報は、エンジンが停止中又は起動中のいずれであるかを示す情報を含み、前記協力車両選定手段は、エンジンが停止中の前記車両を優先して、前記協力車両を選定する請求項2に記載の車両分散処理システム。複数の車両に搭載される複数の車両装置と、前記車両装置とネットワークを介して接続されるセンタ装置と、によって構成される車両分散処理システムによる車両分散処理方法であって、前記車両装置が、自車の走行中に収集されるデータである自車データを記憶するステップと、前記センタ装置が、前記車両装置に処理依頼情報を送信することによって、複数の前記車両装置に協力を依頼するステップと、前記車両装置が、前記処理依頼情報を受信すると、自車の計算リソースに依頼処理を割り当てるステップと、前記依頼処理を割り当てられる前記計算リソースが、前記自車データを参照し、前記依頼処理を実行するステップと、を含む車両分散処理方法。しかしながら、センタ集約型のプローブカーシステムでは、膨大なデータを1箇所に集約し、一括して処理を行う必要がある。従って、特許文献1~3に記載の発明の目的からも分かるように、以下に示す構造的な問題がある。センタ装置に情報を送信する為の通信手段の確保が困難である例えば、個人の携帯端末を利用する通信手段では膨大な通信コストが必要であり、路車間通信や車車間通信を利用する通信手段では常時接続ができない。。通信トラフィックがセンタ装置に集中してしまい、処理効率が悪い。センタ装置の設置コスト及び維持コストが必要になる。特許文献1~3に記載の発明では、これらの問題を部分的に軽減する仕組みが考案されているものの、根本的な解決には至っていない。上記の問題は、交通情報の配信サービスに限らず、走行中に得られる様々なデータを活用する新規のサービスを実現する上で、大きな障壁となっており、解決が望まれている。そこで、本発明者らは、発想を転換し、センタ集約型の仕組みではなく、車両分散型の仕組みによって、上記の課題を解決する。但し、一般的なコンピュータとは異なり、車両に搭載される車両装置の場合、以下のような点に留意する必要がある。主に無線通信手段を使って通信相手センタ装置や他の車両装置とデータをやり取りする必要があるが、データ量が多いままでは、センタ集約型の仕組みの場合と同様、適切な通信手段を確保することができない。走行中に取得される様々なデータ例えば、映像記録型のドライブレコーダによって記録される映像データや、ダイアグレコーダによって記録される車両動作データ等は、運転者や同乗者以下、運転者等という。のプライバシー保護の為、外部の装置に送信することは望ましくない。交通情報の配信サービス等の各サービスに必要なデータは、走行中に車両装置によって収集されるデータのうち、ごく一部であり、全てのデータをセンタ装置が管理することは効率的ではない。車両の主目的は移動することであり、付随的なサービスを実現するための処理によって、走行制御に関わる処理が妨げられてはならない。本発明は、前述した問題点に鑑みてなされたものであり、その目的とすることは、車両特有の課題適切な通信手段を確保すること、運転者等のプライバシーを保護すること、走行中に収集されるデータを効率的に管理すること、及び走行制御に関わる処理を妨げないこと等を解決可能な車両分散処理システム等を提供することである。前述した目的を達成するために第1の発明は、複数の車両に搭載される複数の車両装置と、前記車両装置とネットワークを介して接続されるセンタ装置と、によって構成される車両分散処理システムであって、前記センタ装置は、前記車両装置に処理依頼情報を送信することによって、複数の前記車両装置に協力を依頼する協力依頼手段、を具備し、前記車両装置は、自車の走行中に収集されるデータである自車データを記憶する自車データ記憶手段と、前記処理依頼情報を受信すると、自車の計算リソースに依頼処理を割り当てる割り当て手段と、前記計算リソースが、前記自車データ記憶手段に記憶される前記自車データを参照し、前記依頼処理を実行する実行手段と、を具備する車両分散処理システムである。第1の発明によって、車両特有の課題を解決可能な車両分散処理システムを提供することができる。具体的には、車両装置が自車データを記憶するので、通信量及び通信コストを低減することができ、適切な通信手段として、従来の通信手段を利用することができる。また、車両装置が、記憶対象とするデータを、センタ装置から受信する処理依頼情報に応じて動的に変更するようにすれば、走行中に収集されるデータを効率的に管理することができる。前記車両装置は、自車の車両情報を前記センタ装置に通知する通知手段、を具備し、前記センタ装置は、前記車両装置から受信する前記車両情報を記憶する車両情報記憶手段と、前記車両情報記憶手段に記憶される前記車両情報に基づき、協力依頼先の前記車両である協力車両を選定する協力車両選定手段と、を具備することが望ましい。これによって、依頼内容に適するデータを収集可能な車両のみに依頼を行うことができ、効率的にシステムを運用することができる。また、前記割り当て手段は、自車のエンジンが停止中又は起動中のいずれであるかを判定し、停止中の場合には、前記計算リソースが前記依頼処理を実行するときの計算時間及び/又は消費電力に基づいて割り当て処理を行い、起動中の場合には、前記計算リソースが実行しているタスクの優先度に基づいて割り当て処理を行うことが望ましい。これによって、効率的な割り当て処理を行うことができる。また、前記割り当て手段は、自車のエンジンが起動中の場合には、前記計算リソースが実行しているタスクの優先度に応じて前記タスクの実行/中断状態を変更し、前記タスクが中断状態に変更されることによって空きリソースとなる前記計算リソースに前記依頼処理を割り当てることが望ましい。これによって、自車のエンジンが起動中であっても、一時停止中のような場合には、車内タスクの計算負荷が低い計算リソースに対して依頼処理を割り当てることができる。ひいては、効率的な割り当て処理を行うことができる。また、前記車両情報は、エンジンが停止中又は起動中のいずれであるかを示す情報を含み、前記協力車両選定手段は、エンジンが停止中の前記車両を優先して、前記協力車両を選定することが望ましい。これによって、遊休計算リソースを積極的に活用することができる。第2の発明は、複数の車両に搭載される複数の車両装置と、前記車両装置とネットワークを介して接続されるセンタ装置と、によって構成される車両分散処理システムによる車両分散処理方法であって、前記車両装置が、自車の走行中に収集されるデータである自車データを記憶するステップと、前記センタ装置が、前記車両装置に処理依頼情報を送信することによって、複数の前記車両装置に協力を依頼するステップと、前記車両装置が、前記処理依頼情報を受信すると、自車の計算リソースに依頼処理を割り当てるステップと、前記依頼処理を割り当てられる前記計算リソースが、前記自車データを参照し、前記依頼処理を実行するステップと、を含む車両分散処理方法である。第2の発明によって、車両特有の課題を解決可能な車両分散処理方法を提供することができる。本発明により、車両特有の課題適切な通信手段を確保すること、運転者等のプライバシーを保護すること、走行中に収集されるデータを効率的に管理すること、及び走行制御に関わる処理を妨げないこと等を解決可能な車両分散処理システム等を提供することができる。以下図面に基づいて、本発明の実施形態を詳細に説明する。最初に図1~図3を参照しながら、本発明の全ての実施形態に共通する車両分散処理システムのハードウエア構成について説明する。図1は、車両分散処理システムの全体構成を示す図である。図1に示すように、車両分散処理システム1は、複数の協力車両3bにそれぞれ搭載される複数の車両装置5、及び車両装置5とネットワーク9を介して接続されるセンタ装置4によって構成され、車両装置5が分散処理を行うシステムである。センタ装置4は、車両分散処理システム1を統括するセンタ2等に設置される。依頼車両3aは、処理依頼元の車両である。協力車両3bは、協力依頼先の車両である。以下、依頼車両3a及び協力車両3bを総称するときは、車両3と表記する。車両分散処理システム1の構成には、処理を依頼する依頼者が所有する依頼車両3aに搭載される車両装置5や、依頼者が所有する依頼者PCPersonalComputer7等が含まれても良い。依頼車両3aに搭載される車両装置5や依頼者PC7等は、ネットワーク9を介してセンタ装置4に接続され、処理を依頼する旨の要求をセンタ装置4に送信する。また、各車両3の運転者等が、スマートフォン、タブレット端末、ノートPC等に代表される携帯端末を携帯している場合、車両装置5の計算リソースとして、携帯端末を利用しても良い。センタ装置4と車両装置5との間のデータ通信の経路は、様々な経路が存在する。例えば、車両3が路上等を走行中又は停車中の場合、車両装置5は、無線通信によって、ネットワーク9路上等に設置されている路側器を介する場合も含む。を介してセンタ装置4とのデータ通信を行う。また、例えば、車両3が家庭やディーラ店等に停車中の場合、有線通信又は無線通信によって、PC不図示と接続され、PCを介してセンタ装置4とのデータ通信を行う。以下では、センタ装置4と車両装置5とのデータ通信は、車両3の状況に応じて、最適な経路によって実現されるものとして説明する。図2は、車両装置のハードウエア構成図である。車両装置5は、少なくとも、通信装置11、分散処理ECUElectronicControlUnit12、各種センサ13、記憶装置14、出力装置15、車両制御系ECU16、情報系ECU17、携帯端末インタフェース18等を備える。分散処理ECU12、各種センサ13、記憶装置14、出力装置15、車両制御系ECU16、情報系ECU17、携帯端末インタフェース18等は、CANControllerAreaNetwork19等の車載ネットワークを介して互いにデータの送受信を行い、協調して動作を行っている。通信装置11は、他のコンピュータ等からデータを受信するとともに、他のコンピュータ等にデータを送信する。分散処理ECU12は、分散処理を実行する計算リソースの割り当て等を実行するECUである。分散処理ECU12の動作の詳細は後述する。各種センサ13としては、例えば、車速センサ、加速度センサ、振動センサ、車間距離センサ、温度センサ、位置センサ、車載カメラ等が挙げられる。協力車両3bの車両装置5等は、各種センサ13のデータを用いて、依頼される処理の一部を実行する。記憶装置14は、自車の走行中に収集されるデータである自車データを記憶する装置である。記憶装置14には、予め設定される条件に従って自車データが記憶される。自車データとしては、例えば、各種センサ13によって取得される車両動作データや映像データ等が挙げられる。出力装置15は、液晶ディスプレイ、有機ELディスプレイ、ヘッドマウントディスプレイ等の表示装置や、音を出力するスピーカ等である。車両制御系ECU16としては、燃料噴射制御、アイドル回転数制御、サスペンション制御、ステアリング制御、パワーウィンドウ制御、ドアロック制御等を実行するECUが挙げられる。情報系ECU17としては、経路案内や運転支援等を実行するECUが挙げられる。携帯端末インタフェース18は、携帯端末とのデータ送受信を行うインタフェースである。携帯端末インタフェース18は、無線通信でも良いし、有線通信でも良い。図3は、コンピュータのハードウエア構成図である。図1に示すセンタ装置4、依頼者PC7、携帯端末等は、図3に示すコンピュータ8によって実現される。尚、図3のハードウエア構成は一例であり、用途、目的に応じて様々な構成を採ることが可能である。コンピュータ8は、制御部21、記憶部22、メディア入出力部23、通信制御部24、入力部25、表示部26、周辺機器I/F部27等が、バス28を介して接続される。制御部21は、CPUCentralProcessingUnit、ROMReadOnlyMemory、RAMRandomAccessMemory等によって構成される。CPUは、記憶部22、ROM、記録媒体等に格納されるプログラムをRAM上のワークメモリ領域に呼び出して実行し、バス28を介して接続された各装置を駆動制御し、コンピュータ8が行う処理を実現する。ROMは、不揮発性メモリであり、コンピュータ8のブートプログラムやBIOS等のプログラム、データ等を恒久的に保持している。RAMは、揮発性メモリであり、記憶部22、ROM、記録媒体等からロードしたプログラム、データ等を一時的に保持するとともに、制御部21が各種処理を行う為に使用するワークエリアを備える。記憶部22は、HDDHardDiskDrive等であり、制御部21が実行するプログラム、プログラム実行に必要なデータ、OSOperatingSystem等が格納される。プログラムに関しては、OSに相当する制御プログラムや、後述する処理をコンピュータ8に実行させるためのアプリケーションプログラムが格納されている。これらの各プログラムコードは、制御部21により必要に応じて読み出されてRAMに移され、CPUに読み出されて各種の手段として実行される。メディア入出力部23は、データの入出力を行い、例えば、CDドライブ-ROM、-R、-RW等、DVDドライブ-ROM、-R、-RW等等のメディア入出力装置を有する。通信制御部24は、通信制御装置、通信ポート等を有し、コンピュータ8とネットワーク9間の通信を媒介する通信インタフェースであり、ネットワーク9を介して、他のコンピュータ8間との通信制御を行う。ネットワーク9は、有線、無線を問わない。入力部25は、データの入力を行い、例えば、キーボード、マウス等のポインティングデバイス、テンキー等の入力装置を有する。入力部25を介して、コンピュータ8に対して、操作指示、動作指示、データ入力等を行うことができる。表示部26は、液晶パネル等のディスプレイ装置、ディスプレイ装置と連携してコンピュータ8のビデオ機能を実現するための論理回路等ビデオアダプタ等を有する。尚、入力部25及び表示部26は、タッチパネルディスプレイのように、一体でも良い。周辺機器I/Fインタフェース部27は、コンピュータ8に周辺機器を接続させるためのポートであり、周辺機器I/F部27を介してコンピュータ8は周辺機器とのデータの送受信を行う。周辺機器I/F部27は、USBやIEEE1394やRS-232C等で構成されており、通常複数の周辺機器I/Fを有する。周辺機器との接続形態は有線、無線を問わない。バス28は、各装置間の制御信号、データ信号等の授受を媒介する経路である。次に、図4及び図5を参照しながら、ソフトウエア構成について説明する。図4は、センタ装置の機能構成図である。図4に示すように、センタ装置4は、依頼受付機能31、協力車両選定機能32、協力依頼機能33、処理結果解析機能34、車両情報記憶DBdatabase35等を備える。依頼受付機能31は、車両装置5や依頼者PC7等から依頼を受け付ける機能である。車両装置5から依頼される処理の具体例としては、例えば、依頼車両3aの故障診断サービスに必要なデータの収集等が挙げられる。また、依頼者PC7から依頼される処理の別の具体例としては、事故調査サービスに必要なデータの収集等が挙げられる。協力車両選定機能32は、依頼受付機能31によって受け付けられる依頼に協力してもらう協力車両3bを選定する機能である。協力車両選定機能32の詳細は、図7を参照しながら後述する。協力依頼機能33は、協力車両選定機能32によって選定される協力車両3bに協力を依頼する機能である。協力依頼機能33は、協力車両3bに搭載される車両装置5に処理依頼情報を送信することによって、複数の車両装置5に協力を依頼する。処理依頼情報には、例えば、処理ID、処理内容、処理期限、処理重要度或いは処理緊急度等が含まれる。また、協力依頼機能33は、処理依頼情報だけでなく、処理プログラムを車両装置5に送信するようにしても良い。処理プログラムを送信可能とすることによって、予め想定されていない処理についても、協力を依頼することができる。処理結果解析機能34は、複数の車両装置5から返信される処理結果を解析し、依頼車両3aの車両装置5や依頼者PC7に解析結果を送信する機能である。本発明は、複数の協力車両3bにおいて収集される様々なデータを活用する新たなサービスを実現するためのフレームワークを提供するものである。つまり、本発明は、複数のサービスに共通する仕組みを提供するものである。一方、処理結果解析機能34は提供サービス毎に異なる機能なので、詳細な説明を省略する。車両情報記憶DB35は、車両情報を記憶するデータベースである。車両情報には、1予め登録しておく情報、2車両3のエンジンがONになるときに車両装置5から送信される情報、3走行中に車両装置5から送信される情報、4車両3のエンジンがOFFになるときに車両装置5から送信される情報、等がある。1予め登録しておく情報としては、例えば、以下が挙げられる。車両3の識別に用いられる車種や車両ID収集可能なデータ画像データ、センサデータ、CANバスデータ等の種類や仕様計算リソースとして利用可能なECUの仕様2車両3のエンジンがONになるときに車両装置5から送信される情報としては、例えば、以下が挙げられる。予定走行ルートナビゲーションシステム等に入力される情報であり、データ収集の手掛かりとなる。エンジンONの時刻目的地到着予想時刻エンジンOFFとともに、一部の計算リソースが開放されるので、開放される計算リソースに一部の処理を割り当てることによって、処理時間の短縮が期待できる。計算リソースとして利用可能な携帯端末の仕様や使用率計算リソースとして利用可能なECUの使用率現在だけでなく、将来の予測も含む。将来の予測には、予定走行ルートを用いる。3走行中に車両装置5から送信される情報としては、例えば、以下が挙げられる。走行ルートの修正目的地到着予想時刻の修正計算リソースとして利用可能なECU及び携帯端末の使用状況の変化4車両3のエンジンがOFFになるときに車両装置5から送信される情報としては、例えば、以下が挙げられる。エンジンOFF時刻=目的地到着時刻走行済ルートデータ収集の手掛かりとなる。バッテリ残量依頼可能な処理時間の予測に用いる。図5は、車両装置の機能構成図である。図5に示すように、車両装置5は、車両情報通知機能41、割り当て機能42、依頼処理実行機能43、自車データ記憶機能44等を備える。車両情報通知機能41は、自車の車両情報を生成し、センタ装置4に通知する機能である。車両情報通知機能41は、分散処理ECU12によって実現される。車両情報の内容は、図4の車両情報記憶DB35の説明と同様である。車両情報通知機能41は、例えば、車両3のエンジンがONになるタイミング、走行中の任意のタイミング、及び車両3のエンジンがOFFになるタイミングに車両情報を生成し、センタ装置4に通知する。走行中の任意のタイミングとしては、走行ルートが修正されるとき、目的地到着予想時刻が修正されるとき、計算リソースとして利用可能なECU及び携帯端末の使用状況が変化するとき、等が挙げられる。割り当て機能42は、処理依頼情報を受信すると、自車の計算リソースに依頼処理を割り当てる機能である。割り当て機能42は、分散処理ECU12によって実現される。割り当て機能42の詳細は、図8及び図9を参照しながら後述する。依頼処理実行機能43は、割り当て機能42によって割り当てられる計算リソースが、自車データを参照し、依頼処理を実行する機能である。依頼処理実行機能43は、分散処理ECU12、車両制御系ECU16、情報系ECU17、及び携帯端末によって実現される。依頼処理実行機能43は、提供サービス毎に異なるので、詳細な説明を省略する。自車データ記憶機能44は、自車データを記憶する機能である。自車データ記憶機能44は、分散処理ECU12及び記憶装置14によって実現される。記憶対象とするデータは、センタ装置4から受信する処理依頼情報に応じて動的に変更するようにしても良い。変更例としては、各種センサ13によって収集されるデータのサンプリングレートを変えたり、通常は収集されていないデータ車外の映像データ等を収集するようにしたりすることが挙げられる。記憶対象とするデータを動的に変更する理由は、記憶装置14の空き容量と、依頼される処理の精度とのトレードオフの関係を最適にするためである。図6は、車両状態ごとの計算リソース及びバッテリの状況を説明する図である。車両状態は、1エンジンON走行中、2エンジンON一時停車中、3エンジンOFF、の3通りに分けて考える。1エンジンON走行中の場合、以下のことが言える。情報系ECU17が本来実行すべきタスクの計算負荷は中程度であり、優先度は低い。車両制御系ECU16が本来実行すべきタスクの計算負荷は高く、優先度は最も高い。搭乗者がいるので、携帯端末を計算リソースとして活用できる場合がある。バッテリの残量を考慮する必要がないので、バッテリ重要性は低い。2エンジンON一時停車中の場合、以下のことが言える。情報系ECU17が本来実行すべきタスクの計算負荷は中程度であり、優先度は低い。車両制御系ECU16が本来実行すべきタスクの計算負荷は中程度であり、計算量や優先度は低下する。搭乗者がいるので、携帯端末を計算リソースとして活用できる場合がある。バッテリの残量を考慮する必要がないので、バッテリ重要性は低い。3エンジンOFFの場合、以下のことが言える。情報系ECU17が本来実行すべきタスクの計算負荷は低い。車両制御系ECU16が本来実行すべきタスクの計算負荷は低い。搭乗者がいないので、携帯端末を計算リソースとして活用できない。バッテリの残量を考慮する必要があり、バッテリ重要性は高い。図6の点線51内に示すように、エンジンがOFFの車両3の場合、遊休計算リソースを豊富に持っている可能性がある。そこで、本実施の形態では、このような遊休計算リソースを積極的に活用する仕組みとする。また、図6の点線52内に示すように、車両3は走行と停車を繰り返すので、一時停車中に車両制御系ECU16が本来実行すべきタスクの優先度を一時的に下げて、依頼される処理を実行するようにスケジューリングすることも考えられる。図7は、車両選定処理の詳細を示すフローチャートである。車両選定処理は、センタ装置4の制御部21が、協力車両選定機能32によって実行する処理である。センタ装置4の制御部21は、車両情報記憶DB35に記憶されている情報を参照し、依頼内容に適するデータを収集可能な車両3を候補リストに抽出するS11。S11において参照される情報は、車種や車両ID、収集可能なデータの種類や仕様、計算リソースとして利用可能なECUの仕様、予定走行ルート、走行済ルート等である。次に、センタ装置4の制御部21は、車両情報記憶DB35に記憶されている情報を参照し、候補リスト内のエンジンOFFの車両3であって、バッテリ残量に余裕があり、かつ処理期限内に結果を返すことができる車両3を協力車両3bに選定し、候補リストから外すS12。S12において参照される情報は、エンジンON/OFFの区別エンジンONの時刻及びエンジンOFFの時刻より判定可能、バッテリ残量、計算リソースとして利用可能なECUの使用率等である。次に、センタ装置4の制御部21は、必要な台数に到達したか否かを確認するS13。必要な台数に到達している場合S13のYes、センタ装置4の制御部21は、S14に進む。必要な台数に到達していない場合S13のNo、センタ装置4の制御部21は、S15に進む。S14では、センタ装置4の制御部21は、選定台数が必要台数を超過する場合、処理の終了予想時刻の早い方から順に、必要台数分に絞り込む。S15では、センタ装置4の制御部21は、車両情報記憶DB35に記憶されている情報を参照し、候補リスト内のエンジンONの車両3であって、計算リソースに余裕があり、かつ処理期限内に結果を返すことができる車両3を協力車両3bに選定し、候補リストから外す。S15において参照される情報は、エンジンON/OFFの区別エンジンONの時刻及びエンジンOFFの時刻より判定可能、目的地到着予想時刻、計算リソースとして利用可能なECU及び携帯端末の使用率等である。次に、センタ装置4の制御部21は、必要な台数に到達したか否かを確認するS16。必要な台数に到達している場合S16のYes、センタ装置4の制御部21は、S14に進む。必要な台数に到達していない場合S16のNo、センタ装置4の制御部21は、S17に進む。S17では、センタ装置4の制御部21は、車両情報記憶DB35に記憶されている情報を参照し、候補リスト内の車両3であって、処理の終了予想時刻の早い方から順に、必要台数に達するまで協力車両3bに選定し、候補リストから外す。S15において参照される情報は、目的地到着予想時刻、計算リソースとして利用可能なECU及び携帯端末の使用率等である。センタ装置4の制御部21は、S14又はS17の後、車両選定処理を終了する。そして、センタ装置4の制御部21は、協力依頼機能33によって、協力車両3bに協力を依頼する。図8は、第1の分散処理の詳細を示すフローチャートである。第1の分散処理では、車両装置5の分散処理ECU12が、割り当て機能42によって、依頼処理を計算リソースに割り当てる。そして、車両制御系ECU16、情報系ECU17、携帯端末等が、依頼処理を実行する。車両装置5の分散処理ECU12は、センタ装置4から処理依頼情報処理ID、処理内容、処理期限、処理重要度を受信するとS21、自車のエンジンがOFFか否かを確認するS22。エンジンがOFFの場合S22のYes、車両装置5の分散処理ECU12は、S23に進む。エンジンがOFFでない場合=ONの場合S22のNo、車両装置5の分散処理ECU12は、S24に進む。S23では、車両装置5の分散処理ECU12は、処理期限を満たしつつ、バッテリ消費を最小化するように、利用可能な計算リソースに依頼処理を割り当てるS23。また、S24では、車両装置5の分散処理ECU12は、現在の車内タスクの優先度に応じて、利用可能な計算リソースに依頼処理を割り当てるS23。S23又はS24の後、依頼処理が割り当てられる計算リソース車両制御系ECU16、情報系ECU17、携帯端末等は、依頼処理を実行するS25。また、S23又はS24の後、車両装置5の分散処理ECU12は、依頼処理が終了する前に、自車の車両状態が変化するか否かを監視するS26。車両状態は、前述の通り、1エンジンON走行中、2エンジンON一時停車中、3エンジンOFF、の3通りに分けて考える。依頼処理が終了する前に、自車の車両状態が変化している場合S26のYes、車両装置5の分散処理ECU12は、S22から処理を繰り返し、計算リソースの再割り当てを行う。依頼処理が終了する前に自車の車両状態が変化せずS26のNo、依頼処理が終了するとS27、車両装置5の分散処理ECU12は、センタ装置4に処理結果を返信しS28、分散処理を終了する。図9は、第2の分散処理の詳細を示すフローチャートである。第2の分散処理では、車両装置5の分散処理ECU12が、割り当て機能42によって、依頼処理を計算リソースに割り当てる。そして、車両制御系ECU16、情報系ECU17、携帯端末等が、依頼処理を実行する。第1の分散処理と異なる点は、車両制御系ECU16及び情報系ECU17の本来実行すべきタスク以下、車内タスクという。を明示的に考慮している点と、計算時間及び消費電力を明示的に考慮している点である。車両装置5の分散処理ECU12は、センタ装置4から処理依頼情報処理ID、処理内容、処理期限、処理重要度を受信するとS31、自車のエンジンがOFFか否かを確認するS32。エンジンがOFFの場合S32のYes、車両装置5の分散処理ECU12は、S33及びS34に進む。エンジンがOFFでない場合=ONの場合S32のNo、車両装置5の分散処理ECU12は、S35及びS36に進む。S33及びS34では、車両装置5の分散処理ECU12は、利用可能な計算リソースごとに、依頼処理を実行したときの計算時間及び消費電力を算出する。次に、車両装置5の分散処理ECU12は、処理期限を満たし、消費電力が最低となる計算リソースの組合せに依頼処理を割り当てる。S35及びS36では、車両装置5の分散処理ECU12は、依頼処理に対する優先度に応じて、車内タスクの実行/中断状態を変更する。次に、車両装置5の分散処理ECU12は、空いている計算リソースに依頼処理を割り当てる。S33及びS34、又はS35及びS36を実行すると、計算リソースの使用状況が変化するので、車両装置5の分散処理ECU12は、計算リソースの使用状況をセンタ装置4に通知するS37。S37の後、依頼処理が割り当てられる計算リソース車両制御系ECU16、情報系ECU17、携帯端末等は、依頼処理を実行するS38。また、S37の後、車両装置5の分散処理ECU12は、依頼処理を割り当て後、依頼処理が終了する前に、自車の車両状態が変化するか否かを監視するS39。車両状態は、前述の通り、1エンジンON走行中、2エンジンON一時停車中、3エンジンOFF、の3通りに分けて考える。依頼処理を割り当て後、依頼処理が終了する前に、自車の車両状態が変化している場合S39のYes、車両装置5の分散処理ECU12は、S32から処理を繰り返し、計算リソースの再割り当てを行う。依頼処理を割り当て後、依頼処理が終了する前に自車の車両状態が変化せずS39のNo、依頼処理が終了するとS40、車両装置5の分散処理ECU12は、実行中断タスクがあれば、実行再開に変更しS41、センタ装置4に処理結果を返信するとともに、計算リソースの使用状況を通知しS42、分散処理を終了する。以上説明した通り、本実施形態における車両分散処理システム1は、複数の車両3に搭載される複数の車両装置5と、車両装置5とネットワーク9を介して接続されるセンタ装置4と、によって構成される。センタ装置4は、車両装置5に処理依頼情報を送信することによって、複数の車両装置5に協力を依頼する。車両装置5は、自車の走行中に収集されるデータである自車データを記憶し、処理依頼情報を受信すると、自車の計算リソースに依頼処理を割り当てて、計算リソースが、自車データを参照し、依頼処理を実行する。このフレームワークによって、車両特有の課題を解決することが可能となる。まず、車両装置5が自車データを記憶するので、通信量及び通信コストを低減することができ、従来の通信手段を利用してもボトルネックにならない。つまり、適切な通信手段として、従来の通信手段を利用することができる。また、車両装置5が自車データを記憶するので、運転者等のプライバシーを保護することができる。また、車両装置5が、記憶対象とするデータを、センタ装置4から受信する処理依頼情報に応じて動的に変更するようにすれば、記憶装置14の空き容量と、依頼される処理の精度とのトレードオフの関係を最適にすることができる。ひいては、走行中に収集されるデータを効率的に管理することができる。更に、本実施形態における車両分散処理システム1では、車両装置5が、自車の車両情報をセンタ装置4に通知する。センタ装置4は、車両装置5から受信する車両情報を記憶し、車両情報に基づき、協力車両3bを選定する。これによって、依頼内容に適するデータを収集可能な車両3のみに依頼を行うことができ、効率的にシステムを運用することができる。また、車両装置5は、割り当て処理の1例として、自車のエンジンが停止中又は起動中のいずれであるかを判定し、停止中の場合には、計算リソースが依頼処理を実行するときの計算時間及び/又は消費電力に基づいて割り当て処理を行い、起動中の場合には、計算リソースが実行しているタスクの優先度に基づいて割り当て処理を行う。これによって、効率的な割り当て処理を行うことができる。また、車両装置5は、割り当て処理の1例として、自車のエンジンが起動中の場合には、計算リソースが実行しているタスクの優先度に応じてタスクの実行/中断状態を変更し、タスクが中断状態に変更されることによって空きリソースとなる計算リソースに依頼処理を割り当てる。これによって、自車のエンジンが起動中であっても、一時停止中のような場合には、車内タスクの計算負荷が低い計算リソースに対して依頼処理を割り当てることができる。ひいては、効率的な割り当て処理を行うことができる。また、車両情報は、エンジンが停止中又は起動中のいずれであるかを示す情報を含み、センタ装置4は、エンジンが停止中の車両3を優先して、協力車両3bを選定する。これによって、遊休計算リソースを積極的に活用することができる。以下では、図10及び図11を参照しながら、車両分散処理システム1の具体的な適用例について説明する。図10は、故障診断サービスを実現する車両分散処理システム1aにおけるデータフローを示す図である。車両分散処理システム1aでは、故障の可能性がある車両3が依頼元である。まず、依頼車両3aに搭載されている車両装置5aは、故障診断をセンタ装置4に依頼するD11。センタ装置4は、車両情報記憶DB35に記憶されている車両情報を参照し、協力車両3bを選定する。そして、センタ装置4は、処理依頼情報を協力車両3bの車両装置5bに送信するD12。協力車両3bの車両装置5bは、自車の計算リソースに依頼処理を割り当てて、計算リソースが、自車データを参照し、依頼処理を実行する。そして、協力車両3bの車両装置5bは、故障診断に必要なデータをセンタ装置4に送信するD13。センタ装置4は、協力車両3bから受信するデータを解析し、診断結果を依頼車両3aの車両装置5aに送信するD14。図11は、事故調査サービスを実現する車両分散処理システム1bにおけるデータフローを示す図である。車両分散処理システム1bでは、依頼車両3aは、保険会社等のPCが依頼元である。まず、依頼者PC7は、事故発生直後のデータをセンタ装置4に要求するD21。センタ装置4は、車両情報記憶DB35に記憶されている車両情報を参照し、協力車両3bを選定する。そして、センタ装置4は、処理依頼情報を協力車両3bの車両装置5bに送信するD22。協力車両3bの車両装置5bは、自車の計算リソースに依頼処理を割り当てて、計算リソースが、自車データを参照し、依頼処理を実行する。そして、協力車両3bの車両装置5bは、該当するデータをセンタ装置4に送信するD23。センタ装置4は、協力車両3bから受信するデータを収集し、収集データを依頼者PC7に送信するD24。以上、添付図面を参照しながら、本発明に係る車両分散処理システム等の好適な実施形態について説明したが、本発明はかかる例に限定されない。当業者であれば、本願で開示した技術的思想の範疇内において、各種の変更例又は修正例に想到し得ることは明らかであり、それらについても当然に本発明の技術的範囲に属するものと了解される。