JP2024024021A - 移動体管理装置 - Google Patents

Abstract

【課題】実行を指示した処理に対する車両の状態に関する統計データを好適に取得することが可能な移動体管理装置を提供する。【解決手段】ビークルクラウドサーバ３０は、複数の車両の車載端末２０が正常にジョブリクエストＪＲ２を受信できたことを示す受信結果であるアップロードデータＵＤ２を受信し、アップロードデータＵＤ２に基づき、ジョブリクエストＪＲ２を正常に受信できた車両数であるインアクティブ車両数を計数する。また、ビークルクラウドサーバ３０は、ジョブのアクティブ遷移回数が１回以上となるアップロードデータＵＤ２を受信し、当該アップロードデータＵＤ２を送信した車両数及び延べ車両数を表すアクティプ車両数及びアクティブ延べ車両数を計数する。そして、ビークルクラウドサーバ３０は、インアクティブ車両数、アクティプ車両数、アクティブ延べ車両数の情報を含むアップロードデータＵＤ１をサービスクラウドサーバ４０へ送信する。【選択図】図１７

Description

本発明は、データ収集における状態管理の技術に関する。

従来から、車両に設置されたセンサの情報をサーバ装置において収集する技術が知られている。例えば、特許文献１には、車両等の移動体に設置されたセンサの出力に基づいて部分地図の変化点を検出した場合に、当該変化点に関する変化点情報をサーバ装置に送信する運転支援装置が開示されている。

特開２０１６－１５６９７３号公報

車両に関する種々のサービスを提供する会社がそれぞれサーバを運営することで、車両に対してアップロードすべきデータを指定し、車両を管理するサーバ（車両管理サーバ）を介して、サービス提供に必要な車両に関する様々な情報を収集することが今後想定される。このようなシステムでは、車両は、指示されたデータを所定の実行条件を満たすときにアップロードすることをジョブとして認識し、当該ジョブを上述の実行条件が満たされたときに実行することが求められる。

一方、サービス会社のサーバが生成したデータ収集依頼は、車両に配信される保証はなく、車両管理サーバが高負荷である場合や、収集条件を満たす車両がなくデータ収集依頼を配信すべき車両が存在しない場合などでは、車両に配信されない。また、車両側が高負荷となり車両からデータ収集依頼が削除された場合などでは、データ収集依頼は車両により適切に実行されない。以上を勘案した場合、データ収集依頼の有効性やコスト効率、収集データの信頼性などを的確に把握するには、各車両に実行を指示した処理の状態を適切に管理する必要がある。

本発明は、上記のような課題を解決するためになされたものであり、移動体に実行を指示した処理の状態に関する統計データを好適に取得することが可能な移動体管理装置を提供することを主な目的とする。

請求項に記載の発明は、移動体管理装置であって、複数の移動体に対して情報管理装置からの要求信号に基づく指令情報を送信する第１送信部と、前記指令情報を正常に受信できた移動体の数を計数する第１計数部と、前記指令情報に対する応答情報を受信する受信部と、前記応答情報に基づき、前記応答情報を送信した移動体の数を計数する第２計数部と、前記正常に受信できた移動体の数と、前記応答情報を送信した移動体の数とに関する移動体数情報と、のうち少なくとも一方を前記情報管理装置に送信する第２送信部と、
を備える。

第１実施例に係るジョブ配信システムの概略構成を示す。 車載端末と、ビークルクラウドサーバと、サービスクラウドサーバとの間のデータの流れを概略的に示した図である。 車載端末の内部構成を示すブロック図である。 ジョブに対する車載端末の状態遷移を概略的に示した図である。 ビークルクラウドサーバ及びサービスクラウドサーバの内部構成を示すブロック図である。 ジョブリクエストのデータ構造の一例である。 送信履歴情報のデータ構造の一例である。 車載端末がジョブリクエストに基づきビークルクラウドサーバに対して送信するアップロードデータのデータ構造の一例である。 ビークルクラウドサーバがジョブリクエストに基づきサービスクラウドサーバに対して送信するアップロードデータのデータ構造の一例である。 有効な状態管理フラグが含まれるジョブリクエストを受信した場合に車載端末が実行する処理手順を示すフローチャートである。 有効な状態管理フラグを含むジョブリクエストを受信したビークルクラウドサーバが実行する処理手順を示すフローチャートを示す。 適用例におけるジョブ配信システムの構成例を示す。 Ａ駅の駅前通りを示した俯瞰図である。 第２実施例に係る車載端末の内部構成を示すブロック図である。 第２実施例に係るアップロードデータのデータ構造の一例である。 有効な状態管理フラグが含まれるジョブリクエストを受信した場合に第２実施例に係る車載端末が実行する処理手順を示すフローチャートである。 有効な状態管理フラグを含むジョブリクエストを受信した第２実施例に係るビークルクラウドサーバが実行する処理手順を示すフローチャートを示す。 第３実施例に係るアップロードデータのデータ構造の一例である。 第３実施例に係るビークルクラウドサーバの内部構成を概略的に示した図である。 有効な状態管理フラグを含むジョブリクエストを受信した第３実施例に係る車載端末が実行する処理手順を示すフローチャートである。 有効な状態管理フラグを含むジョブリクエストを受信した第３実施例に係るビークルクラウドサーバが実行する処理手順を示すフローチャートを示す。

１つの好適な実施形態は、移動体管理装置であって、情報管理装置が発した要求信号を受信する第１受信部と、前記要求信号に応じた指令情報を生成する生成部と、複数の移動体に対して前記指令情報を送信する第１送信部と、前記複数の移動体が正常に前記指令情報を受信できたことを示す受信結果を受信する第２受信部と、前記受信結果に基づき、前記指令情報を正常に受信できた移動体の数を計数する第１計数部と、前記指令情報に対する応答情報を受信する第３受信部と、前記応答情報に基づき、前記応答情報を送信した移動体の数を計数する第２計数部と、前記正常に受信できた移動体の数と、前記応答情報を送信した移動体の数とに関する移動体数情報を、前記情報管理装置に送信する第２送信部と、を備える。「移動体の数」は、延べ数であってもよい。この態様により、移動体管理装置は、要求信号に基づく指令情報を正常に受信した移動体の数と、指令情報に対する応答情報を送信した移動体の数とに関する移動体数情報を、情報管理装置に好適に供給することができる。

上記移動体管理装置の一態様では、前記指令情報は、前記移動体が前記指令情報の示す指令を実行する条件を示す条件情報を含み、前記応答情報は、前記条件が満たされたか否かに応じて前記指令情報が取り得る状態に関する情報を含む。この態様により、移動体管理装置は、条件情報が示す条件が満たされたか否かに応じて指令情報が取り得る状態に関する情報を、移動体ごとに取得することができるため、上述した移動体の数を的確に計数することができる。

上記移動体管理装置の他の一態様では、前記第１送信部は、前記指令情報と、前記前記指令情報が取り得る状態に関する情報の送信を指示するフラグ情報と、を前記複数の移動体に送信する。この態様により、移動体管理装置は、指令情報が取り得る状態に関する情報を、移動体から好適に収集することができる。

上記移動体管理装置の他の一態様では、前記指令情報が取り得る状態は、前記条件が満たされた場合に前記指令が実行される状態である実行状態と前記条件が満たされない場合に前記指令が実行されない状態である非実行状態と、含み、前記第２送信部は、前記移動体数情報として、前記正常に受信できた移動体の数に対する前記指令情報が前記実行状態報となった移動体の数の割合を示す情報を前記情報管理装置に送信する。この態様により、要求信号の有効性やコスト効率の判定に必要な情報を好適に情報管理装置に供給することができる。

上記移動体管理装置の他の一態様では、前記移動体管理装置は、前記第１送信部が前記指令情報を送信した移動体の識別情報と、当該指令情報が示す指令の識別情報と、を関連付けて記憶する記憶部を更に備える。この態様により、移動体管理装置は、送信した指令情報ごとに、指令情報の送信先となる移動体の数を好適に保持することができる。

上記移動体管理装置の他の一態様では、前記受信結果は、前記指令情報が正常に受け付けられなかったことを示すフェール情報を含む。この態様により、移動体管理装置は、指令情報を正常に受け付けた移動体の数を的確に計数することができる。

さらに別の好適な実施形態では、移動体管理装置が実行する制御方法であって、情報管理装置が発した要求信号を受信する第１受信工程と、前記要求信号に応じた指令情報を生成する生成工程と、複数の移動体に対して前記指令情報を送信する第１送信工程と、前記複数の移動体が正常に前記指令情報を受信できたことを示す受信結果を受信する第２受信工程と、前記受信結果に基づき、前記指令情報を正常に受信できた移動体の数を計数する第１計数工程と、前記指令情報に対する応答情報を受信する第３受信工程と、前記応答情報に基づき、前記応答情報を送信した移動体の数を計数する第２計数工程と、前記正常に受信できた移動体の数と、前記応答情報を送信した移動体の数とに関する移動体数情報を、前記情報管理装置に送信する第２送信工程と、を有する。移動体管理装置は、この制御方法を実行することで、要求信号に基づく指令情報を正常に受信した移動体の数と、指令情報に対する応答情報を送信した移動体の数とに関する移動体数情報を、情報管理装置に好適に供給することができる。

さらに別の好適な実施形態は、上記記載の制御方法を、コンピュータにより実行させるプログラムである。コンピュータは、このプログラムを実行することで、処理情報を送信した端末装置の数を、処理情報が示す処理の内容ごとに、好適に把握することができる。好適には、上記プログラムは、記憶媒体に記憶される。

以下、図面を参照して本発明の好適な第１～第３実施例について説明する。
＜第１実施例＞
（１）全体構成
図１は、第１実施例に係るジョブ配信システムの概略構成を示す。ジョブ配信システムは、車両のセンサが生成した種々の情報を収集するためのシステムであり、車両Ｖと、ビークル（ＶＥＨＩＣＬＥ）クラウドサーバ３０と、サービスクラウドサーバ４０とを備える。

車両Ｖには、車載端末２０が搭載されている。車載端末２０は、車両Ｖの状態又は周辺環境に関する情報を取得するための種々のセンサと接続し、所定の処理を行う情報処理装置である。車載端末２０は、これらのセンサの出力に基づき、サービスクラウドサーバ４０から依頼された処理（単に「ジョブ」とも呼ぶ。）を実行する。本実施例では、ジョブは、主に、サービスクラウドサーバ４０から指定された特定の車両Ｖの状態又は周辺環境に関する情報をセンサにより取得してサービスクラウドサーバ４０にアップロードする処理を指す。車両Ｖ及び車載端末２０は、「移動体」の一例である。また、車載端末２０は、「端末装置」の一例である。尚、「移動体」は車両Ｖ及び車載端末２０に限られず、自転車、車椅子、ドローン、船舶等の移動体であってもよい。

ビークルクラウドサーバ３０は、ビークルクラウドを構成するサーバ装置である。ビークルクラウドとは、例えば、ユーザに提供された車両（例えば自動運転車）を管理し、車両から各種の情報を収集する情報収集会社が運営するクラウドである。情報収集会社は、自動車メーカー自身がその役割を担ってもよく、また、自動車メーカーによって直接、または間接的に運営されてもよい。例えば、自動車メーカーとしてＡ社、Ｂ社、Ｃ社の３社が存在する場合、Ａ社が運営する情報収集会社、Ｂ社が運営する情報収集会社、Ｃ社が運営する情報収集会社が個別に存在し、各情報収集会社は運営する自動車メーカーが製造した車両から各種の情報を収集する。あるいは、Ｄ社、Ｅ社、Ｆ社などの複数の自動車メーカーが共同で委託／運営する形態でもよい。ビークルクラウドサーバ３０は、「移動体管理装置」の一例である。

サービスクラウドサーバ４０は、サービスクラウドを構成するサーバ装置である。サービスクラウドとは、例えば、車両に関するサービスを提供するサービス提供会社が運営するクラウドである。サービス提供会社としては、保険に関するサービスを提供する保険会社、地図に関するサービスを提供する地図サービス会社、駐車場に関するサービスを提供する駐車場サービス会社、経路探索に関するサービスを提供する経路探索サービス会社などが挙げられる。サービスクラウドサーバ４０は、目的に応じて、車載端末２０に実行させるジョブを指示する情報（「ジョブリクエスト」とも呼ぶ。）を生成し、ビークルクラウドサーバ３０を介して車載端末２０に配信する。サービスクラウドサーバ４０は、「情報管理装置」の一例である。

車両Ｖに搭載されている車載端末２０と、ビークルクラウドサーバ３０と、サービスクラウドサーバ４０とは、ネットワーク５を通じて有線又は無線により通信が可能である。本実施例では、車載端末２０と、ビークルクラウドサーバ３０と、サービスクラウドサーバ４０とは、サービスクラウドサーバ４０が生成したジョブリクエストの授受、及び、ジョブリクエストに応じて車載端末２０が生成したデータ（「アップロードデータ」とも呼ぶ。）の授受を行う。

なお、図１に示すジョブ配信システムの構成は一例であり、本発明が適用可能な構成はこれに限定されない。例えば、サービスクラウドとして、ジョブリクエストを生成するサービスクラウド（第１サービスクラウド）と、第１サービスクラウドに所定の情報の収集を依頼するサービスクラウド（第２サービスクラウド）とが存在してもよい。この場合、例えば、第１サービスクラウドは、第２サービスクラウドの依頼内容に応じてジョブリクエストを生成し、かつ、ジョブリクエストの送信先のビークルクラウドから受信したアップロードデータに基づいて、第２サービスクラウドが求める情報を第２サービスクラウドに送信する。

図２は、車載端末２０と、ビークルクラウドサーバ３０と、サービスクラウドサーバ４０との間のデータの流れを概略的に示した図である。

図２に示すように、サービスクラウドサーバ４０は、生成したジョブリクエスト「ＪＲ１」をビークルクラウドサーバ３０に送信し、ビークルクラウドサーバ３０は、サービスクラウドサーバ４０から受信したジョブリクエストＪＲ１に基づき生成したジョブリクエスト「ＪＲ２」を、車載端末２０に送信する。なお、ジョブリクエストＪＲ１には、ジョブを実行すべき車両を示す車両ＩＤやドライバＩＤなどを含めることが可能となっており、サービスクラウドサーバ４０は、必要に応じて、送信対象とする車両ＩＤやドライバＩＤをジョブリクエストＪＲ１に含める。これにより、ビークルクラウドサーバ３０は、対応する車両の車載端末２０に対してジョブリクエストＪＲ２を送信する。

ジョブリクエストＪＲ２を受信した車載端末２０は、ジョブリクエストＪＲ２において指定されたデータをセンサより収集し、収集したデータをアップロードデータ「ＵＤ２」としてビークルクラウドサーバ３０に送信する。ビークルクラウドサーバ３０は、車載端末２０からアップロードデータＵＤ２を受信した場合、受信したアップロードデータＵＤ２に基づきアップロードデータ「ＵＤ１」を生成し、生成したアップロードデータＵＤ１を依頼元のサービスクラウドサーバ４０へ送信する。ジョブリクエストＪＲ１、ＪＲ２及びアップロードデータＵＤ１、ＵＤ２のデータ構造については、「（５）データ構造」のセクションにて詳しく説明する。サービスクラウドサーバ４０がビークルクラウドサーバ３０へ送信するジョブリクエストＪＲ１は、「要求信号」の一例であり、ビークルクラウドサーバ３０から車載端末２０に送信するジョブリクエストＪＲ２は、「送信情報」の一例であり、アップロードデータＵＤ２は、「受信結果」の一例である。

（２）車載端末の構成
図３は、車載端末２０の内部構成を示すブロック図である。図示のように、車載端末２０は、主に、通信部２１と、記憶部２２と、入力部２３と、制御部２４と、インターフェース２５と、出力部２６とを有する。車載端末２０内の各要素は、バスライン２９を介して相互に接続されている。また、インターフェース２５は、センサ部２７と接続されている。

通信部２１は、制御部２４の制御に基づき、アップロードデータをビークルクラウドサーバ３０へ送信したり、地図ＤＢを更新するための地図データをビークルクラウドサーバ３０から受信したりする。また、通信部２１は、車両を制御するための信号を車両に送信する処理、車両の状態に関する信号を車両から受信する処理を行ってもよい。

記憶部２２は、制御部２４が実行するプログラムや、制御部２４が所定の処理を実行する為に必要な情報を記憶する。記憶部２２は、不揮発性メモリ（内部ストレージ）を含んでいる。本実施例では、記憶部２２は、地図ＤＢと、センサデータキャッシュと、車両属性情報と、通信部２１によりビークルクラウドサーバ３０から受信したジョブリクエストＪＲ２と、状態カウント情報と、を記憶する。

地図ＤＢは、例えば、道路データ、施設データ、及び、道路周辺の地物データなどを含むデータベースである。道路データには、経路探索用の車道／車線ネットワークデータ、道路形状データ、交通法規データなどが含まれる。地物データは、道路標識等の看板や停止線等の道路標示、センターライン等の道路区画線や道路沿いの構造物等の情報を含む。また、地物データは、自車位置推定に用いるための地物の高精度な点群情報などを含んでもよい。その他、地図ＤＢには、位置推定に必要な種々のデータが記憶されてもよい。

センサデータキャッシュは、センサ部２７の出力データを一時的に保持するキャッシュメモリである。車両属性情報は、車両の種別、車両ＩＤ、車両長さ、車幅、車高などの車両サイズ、車両の燃料タイプなど、車載端末２０を搭載した車両Ｖの属性に関する情報を示す。

状態カウント情報は、ジョブリクエストＪＲ２により依頼されたジョブが有効な期間における当該ジョブの状態ごとの累積の遷移回数を示す情報である。状態カウント情報は、例えば、ジョブが取り得る状態ごとに、当該状態への遷移回数が関連付けられた情報である。制御部２４は、上述の状態の遷移を検知する毎に、状態カウント情報を更新する。ジョブの状態遷移については、図４を用いて後述する。状態カウント情報は、「計数情報」の一例である。

入力部２３は、ユーザが操作するためのボタン、タッチパネル、リモートコントローラ、音声入力装置等であり、例えば、経路探索のための目的地を指定する入力、自動運転のオン及びオフを指定する入力などを受け付け、生成した入力信号を制御部２４へ供給する。出力部２６は、例えば、制御部２４の制御に基づき出力を行うディスプレイやスピーカ等である。

インターフェース２５は、センサ部２７の出力データを制御部２４やセンサデータキャッシュに供給するためのインターフェース動作を行う。センサ部２７は、ライダやカメラなどの車両の周辺環境を認識するための複数の外界センサと、ＧＰＳ受信機、ジャイロセンサ、ポジションセンサ、３軸センサなどの内界センサを含む。ライダは、外界に存在する物体までの距離を離散的に測定し、当該物体の表面を３次元の点群として認識し、点群データを生成する。カメラは、車両から撮影した画像データを生成する。ポジションセンサは、各外界センサの位置を検出するために設けられ、３軸センサは、各外界センサの姿勢を検出するために設けられている。なお、センサ部２７は、図３に示した外界センサ及び内界センサ以外の任意の外界センサ及び内界センサを有してもよい。例えば、センサ部２７は、外界センサとして、超音波センサ、赤外線センサ、マイクなどを含んでもよい。

制御部２４は、１または複数のプラットフォーム上で所定のプログラムを実行するＣＰＵなどを含み、車載端末２０の全体を制御する。制御部２４は、機能的には、位置推定部と、オブジェクト検出部と、アップロードデータ生成部とを含む。制御部２４は、プログラムを実行するコンピュータとして機能する。制御部２４は、「生成部」及びプログラムを実行するコンピュータの一例であり、通信部２１及び制御部２４は、「受信部」及び「送信部」の一例である。

位置推定部は、センサデータキャッシュに保持されているセンサ部２７の出力データ及び地図ＤＢに基づき、自車位置（車両の姿勢も含む）を推定する。位置推定部は、種々の位置推定方法を実行可能となっている。位置推定部は、例えば、ＧＰＳ受信機及びジャイロセンサ等の自立測位センサの出力に基づくデッドレコニング（自律航法）による自車位置推定方法、自律航法に地図ＤＢの道路データなどをさらに照合する処理（マップマッチング）を行う自車位置推定方法、周囲に存在する所定のオブジェクト（ランドマーク）を基準としてライダやカメラなどの外界センサの出力データと地図ＤＢの地物情報が示すランドマークの位置情報とに基づく自車位置推定方法などを実行する。そして、位置推定部は、現在実行可能な位置推定方法の中から最も高い推定精度となる位置推定方法を実行し、実行した位置推定方法に基づき得られた自車位置等を示した自車位置情報を、アップロードデータ生成部へ供給する。

オブジェクト検出部は、センサ部２７が出力する点群情報、画像データ、音声データ等に基づき、所定のオブジェクトを検出する。この場合、例えば、オブジェクト検出部は、位置推定部が推定した自車位置に基づき、センサ部２７により検出したオブジェクトに対応する地物データを地図ＤＢから抽出する。そして、オブジェクト検出部は、例えば、センサ部２７により検出したオブジェクトの位置及び形状等と、地図ＤＢから抽出した地物データが示すオブジェクトの位置及び形状等とに違いがある場合、又は、地図ＤＢに該当する地物データが存在しない場合などに、センサ部２７により検出したオブジェクトに関する情報を、アップロードデータ生成部へ供給する。

アップロードデータ生成部は、位置推定部から供給される自車位置情報、オブジェクト検出部から供給されるオブジェクトデータ、及びセンサデータキャッシュから供給されるセンサ部２７の出力データなどに基づき、アップロードデータＵＤ２を生成する。本実施例では、アップロードデータ生成部は、記憶部２２に記憶されたジョブリクエストＪＲ２が指定する条件を満たすときに同データが指定するデータをアップロードデータＵＤ２に含め、通信部２１によりビークルクラウドサーバ３０へアップロードデータＵＤ２を送信する。

ここで、ジョブリクエストＪＲ２が示すジョブの状態（単に「ジョブ状態」とも呼ぶ。）の遷移について説明する。

図４は、ジョブ状態の遷移を概略的に示した図である。図４には、ジョブリクエストＪＲ２が示すジョブの実行条件を満たさないジョブ状態であるインアクティブ状態（非実行状態）と、ジョブの実行条件を満たすジョブ状態であるアクティブ状態（実行状態）と、例外的な場合に遷移するフェール（Ｆａｉｌｅｄ）とが記されている。

ここで、車載端末２０は、ジョブリクエストＪＲ２を受信した場合には、所定の認証処理を行い、ジョブリクエストＪＲ２を受け付けることが適切であるか否かを判定する。例えば、車載端末２０は、認証処理として、ジョブリクエストＪＲ２において指定された車両ＩＤ又は／及びドライバＩＤが車両Ｖの車両ＩＤ又は／及び車両ＶのドライバのドライバＩＤとが一致するか否か判定する。

そして、認証処理が成功した場合には、ジョブはインアクティブ状態に自動的に遷移する。その後、ジョブリクエストＪＲ２が示すジョブの実行条件を満たすと判断した場合には、当該ジョブはアクティブ状態に遷移し、アクティブ状態に遷移後に上述の実行条件を満たさないと判断した場合には、当該ジョブはインアクティブ状態に遷移する。

一方、認証処理が失敗した場合には、ジョブはフェールに移行する。そして、車載端末２０は、この場合、フェールとなった旨のアップロードデータＵＤ２をビークルクラウドサーバ３０へ送信する。なお、所定の例外が発生した場合には、ジョブをアクティブ状態又はインアクティブ状態からフェールに移行してもよい。そして、車載端末２０は、ジョブの有効期限等が終了した場合又はフェールになった場合などにジョブを終了し、ジョブリクエストＪＲ２を記憶部２２から削除する。フェールとなった旨のアップロードデータＵＤ２は、「フェール情報」の一例である。

（３）ビークルクラウドサーバの構成
次に、ビークルクラウドサーバ３０について詳しく説明する。図５（Ａ）はビークルクラウドサーバ３０の内部構成を示すブロック図である。図示のように、ビークルクラウドサーバ３０は、通信部３１と、記憶部３２と、制御部３３とを備える。ビークルクラウドサーバ３０内の各要素は、バスライン３９を介して相互に接続されている。

通信部３１は、制御部３３の制御に基づき、車両Ｖの車載端末２０及びサービスクラウドサーバ４０と通信する。具体的には、通信部３１は、サービスクラウドサーバ４０からジョブリクエストＪＲ１を受信したり、当該ジョブリクエストＪＲ１に基づき生成されたジョブリクエストＪＲ２を車載端末２０へ送信したりする。また、通信部３１は、車載端末２０からアップロードデータＵＤ２を受信したり、当該アップロードデータＵＤ２に基づき生成したアップロードデータＵＤ１をサービスクラウドサーバ４０へ送信したりする。

記憶部３２は、ＲＯＭ、ＲＡＭなどを含み、ビークルクラウドサーバ３０が実行する各種の処理のためのプログラムが記憶されている。また、記憶部３２は、各種の処理が実行される際の作業メモリとしても使用される。また、記憶部３２は、車両情報と、送信履歴情報Ｉｈとを記憶している。車両情報は、ビークルクラウドが管理する車両に関する情報である。車両情報は、例えば、車両ごとに、車両ＩＤ又は／及びドライバＩＤと、対応する車両の車載端末２０へデータを送信するための通信アドレス情報と、車両が利用しているサービスに関する情報とを対応付けたテーブル情報である。送信履歴情報Ｉｈは、ジョブリクエストＪＲ２を各車両の車載端末２０に送信した履歴を示すテーブルであり、詳細なデータ構造については後述する。

また、記憶部３２は、ビークルクラウドサーバ３０がサービスクラウドサーバ４０から受信したジョブリクエストＪＲ１、及び、ビークルクラウドサーバ３０が車載端末２０から取得したアップロードデータＵＤ２の履歴データをさらに記憶してもよい。この場合、例えば、記憶部３２には、各車載端末２０から受信したアップロードデータＵＤ２が、車載端末２０を搭載している車両Ｖの車両ＩＤや受信時刻などと関連付けて記憶される。同様に、記憶部３２には、サービスクラウドサーバ４０から受信したジョブリクエストＪＲ１が、送信元のサービスクラウドサーバ４０を特定する情報及び受信時刻などと関連付けて記憶されてもよい。

制御部３３は、ＣＰＵなどのコンピュータにより構成され、ビークルクラウドサーバ３０の全体を制御する。具体的には、制御部３３は、記憶部３２に記憶された各種のプログラムを実行することにより、各種の処理を行う。制御部３３は、「生成部」、「計数部」、「第１計数部」、「第２計数部」の一例である。また、通信部３１及び制御部３３は、「第１受信部」、「第１送信部」、「第２受信部」、「第３受信部」、「第２送信部」の一例である。

（４）サービスクラウドサーバの構成
次に、サービスクラウドサーバ４０について詳しく説明する。図５（Ｂ）はサービスクラウドサーバ４０の内部構成を示すブロック図である。図示のように、サービスクラウドサーバ４０は、通信部４１と、記憶部４２と、制御部４３とを備える。サービスクラウドサーバ４０内の各要素は、バスライン４９を介して相互に接続されている。

通信部４１は、制御部４３の制御に基づき、ビークルクラウドサーバ３０と通信する。具体的には、通信部４１は、後述する提供情報に該当する情報をビークルクラウドサーバ３０から受信する。

記憶部４２は、不揮発性メモリであるＲＯＭ及び揮発性メモリであるＲＡＭなどを含み、サービスクラウドサーバ４０が実行する各種の処理のためのプログラムが記憶されている。また、記憶部４２は、各種の処理が実行される際の作業メモリとしても使用される。また、記憶部４２は、サービスクラウドサーバ４０がビークルクラウドサーバ３０に対して送信したジョブリクエストＪＲ１、及び、サービスクラウドサーバ４０がビークルクラウドサーバ３０から取得したアップロードデータＵＤ１の履歴を記憶してもよい。この場合、例えば、ジョブリクエストＪＲ１及びアップロードデータＵＤ１は、送信先又は送信元のビークルクラウドサーバ３０を特定する情報及び送受信時刻などと関連付けられて記憶部４２に記憶される。

制御部４３は、ＣＰＵなどのコンピュータにより構成され、サービスクラウドサーバ４０の全体を制御する。具体的には、制御部４３は、記憶部４２に記憶された各種のプログラムを実行することにより、各種の処理を行う。

（５）データ構造
次に、各種データのデータ構造について説明する。以後では、ジョブリクエストＪＲ１とジョブリクエストＪＲ２とを区別しない場合には、単に「ジョブリクエスト」と表記し、アップロードデータＵＤ１とアップロードデータＵＤ２とを区別しない場合には、単に「アップロードデータ」と表記する。
（５－１）ジョブリクエスト
図６は、ジョブリクエストのデータ構造の一例である。図示のように、ジョブリクエストは、「バージョン情報」と、「リクエスト識別情報」と、「属性情報」と、「データ収集条件情報」と、「状態管理フラグ」と、「収集データ指定情報」とを含む。

「バージョン情報」は、ジョブリクエストを規定した仕様のバージョン等を識別する情報である。「属性情報」は、対象のジョブリクエストの取り扱いを規定した情報である。

「リクエスト識別情報」は、サービスクラウドサーバ４０が生成するジョブリクエストＪＲ１に固有の識別情報である。サービスクラウドサーバ４０は、ジョブリクエストＪＲ１を生成する度に、ユニークなリクエスト識別情報を生成してジョブリクエストＪＲ１に含める。なお、ジョブリクエストＪＲ２の「リクエスト識別情報」は、ジョブリクエストＪＲ１の「リクエスト識別情報」と同一であってもよく、異なっていてもよい。後者の場合、ビークルクラウドサーバ３０は、車載端末２０に送信するジョブリクエストＪＲ２ごとに固有の識別情報をジョブリクエストＪＲ２の「リクエスト識別情報」として設定する。この場合、例えば、ビークルクラウドサーバ３０は、ジョブリクエストＪＲ１の「リクエスト識別情報」と当該ジョブリクエストＪＲ１に基づき生成したジョブリクエストＪＲ２の「リクエスト識別情報」とを対応付けるテーブル等を記憶しておく。本実施例において、ジョブリクエストＪＲ１の「リクエスト識別情報」は、ジョブを識別する情報（ジョブＩＤ）として用いられる。

「データ収集条件情報」は、データを収集する条件を示す情報である。例えば、「データ収集条件情報」は、車載端末２０がアップロードデータＵＤ２を生成する地理的条件、アップロードデータＵＤ２を生成する時間的条件、イベント、車両Ｖの車両ＩＤ、又は／及び車両Ｖの運転者のドライバＩＤを示す情報である。ここで、上述のアップロードデータＵＤ２を生成する地理的条件とは、例えば、アップロードデータＵＤ２を生成する道路又はエリアを指定する条件であり、アップロードデータＵＤ２を生成する時間的条件とは、例えば、アップロードデータＵＤ２を生成する時間帯やインターバルなど、時間的な制約を指定する条件である。また、イベントとは、アップロードデータＵＤ２を生成する契機となるイベント等を示し、例えば、所定度合以上の衝撃（即ち事故）の発生や急ブレーキの発生などが上述のイベントとして指定される。データ収集条件情報は、「条件情報」の一例である。

「収集データ指定情報」は、データ収集条件情報が示すジョブの実行条件を満たす場合にアップロードデータとして含めるべき収集データを指定する情報である。収集データ指定情報は、例えば、車両の加減速に関する情報、車速に関する情報、車両の走行軌跡（即ち時系列での自車位置・姿勢）の情報、出発地及び目的地の情報、事故発生前後所定時間におけるカメラの撮影情報などである。データ収集条件情報及び収集データ指定情報として指定される内容は、ジョブリクエストを生成するサービスクラウドサーバ４０が運営するサービス会社によって夫々任意に設定される。データ収集条件情報及び収集データ指定情報は、「指令情報」の一例である。

「状態管理フラグ」は、状態カウント情報のアップロードの要否を指定するフラグ（「状態管理フラグＦｓ」とも呼ぶ。）である。例えば、状態管理フラグＦｓは、無効であることを示す「０」または有効であることを示す「１」のいずれかの値となり、１（有効）である場合には、状態カウント情報のアップロードが必要であることを示し、０（無効）である場合には、状態カウント情報のアップロードが不要であることを示す。状態管理フラグＦｓは、フラグ情報の一例である。なお、状態管理フラグＦｓは、ジョブリクエスト内の単独のフィールドに設けられる代わりに、データ収集条件情報、属性情報又は収集データ指定情報のいずれかのフィールドに含まれてもよい。

ここで、サービスクラウドサーバ４０からビークルクラウドサーバ３０に送信されるジョブリクエストＪＲ１に、有効な状態管理フラグＦｓが含まれる場合には、ビークルクラウドサーバ３０は、ジョブリクエストＪＲ１が示すジョブに対し、ジョブ状態に関する車両数の集計を行う。そして、ビークルクラウドサーバ３０は、その集計結果をアップロードデータＵＤ１としてサービスクラウドサーバ４０に送信する。上述の集計結果を含むアップロードデータＵＤ１のデータ構造については、図９を参照して後述する。

また、ビークルクラウドサーバ３０から各車載端末２０に送信されるジョブリクエストＪＲ２に、有効な状態管理フラグＦｓが含まれる場合には、車載端末２０は、ビークルクラウドサーバ３０が上述のジョブ状態に関する車両数の集計に必要な情報を生成する。そして、車載端末２０は、生成した情報をアップロードデータＵＤ２に含めてビークルクラウドサーバ３０に送信する。車載端末２０が送信するアップロードデータＵＤ２のデータ構造については、図８を参照して後述する。

なお、ジョブリクエストは、図６に示した情報以外の任意の情報を含んでもよい。例えば、ジョブリクエストには、ジョブリクエストの生成元であるサービスクラウドサーバ４０又はビークルクラウドサーバ３０へアップロードデータを送信するための送信先を指定したアドレス情報などが含まれてもよい。他の例では、ジョブリクエストには、リクエスト識別情報とは別に、ジョブを識別するためのジョブＩＤが含まれてもよい。例えば、サービスクラウドサーバ４０が同一内容のジョブを示すジョブリクエストＪＲ１を複数のビークルクラウドサーバ３０に送信する場合には、各ジョブリクエストＪＲ１には、ジョブリクエストＪＲ１ごとに異なるリクエスト識別情報と、全てのジョブリクエストＪＲ１で共通のジョブＩＤとが含まれてもよい。

（５－２）送信履歴情報
図７は、送信履歴情報Ｉｈのデータ構造の一例である。送信履歴情報Ｉｈは、ジョブリクエストＪＲ２の送信履歴に相当し、図７の例では、「車両ＩＤ」と、「ジョブＩＤ」とを少なくとも含んでいる。

「車両ＩＤ」は、送信履歴情報Ｉｈを保持するビークルクラウドサーバ３０がジョブリクエストＪＲ２を送信した送信先の車載端末２０に対応する車両ＩＤである。「ジョブＩＤ」は、車載端末２０へ送信したジョブリクエストＪＲ２により依頼したジョブの識別情報である。例えば、ビークルクラウドサーバ３０は、送信履歴情報Ｉｈの「ジョブＩＤ」として、ジョブリクエストＪＲ２の生成に用いたジョブリクエストＪＲ１のリクエスト識別情報を記録してもよい。

ビークルクラウドサーバ３０は、ジョブリクエストＪＲ２を車載端末２０に送信するごとに、自身が保持する送信履歴情報Ｉｈに、車両ＩＤ及びジョブＩＤを関連付けたレコードを追加する。なお、送信履歴情報Ｉｈには、車両ＩＤ及びジョブＩＤ以外の任意の項目を含んでもよい。例えば、送信履歴情報Ｉｈには、車載端末２０へ送信したジョブリクエストＪＲ２を生成するのに用いたジョブリクエストＪＲ１の生成元のサービスクラウドの識別情報がさらに含まれてもよい。この識別情報は、サービスクラウドを識別するための任意の情報（例えば通信アドレス等）であってもよい。

また、ビークルクラウドサーバ３０は、ジョブリクエストＪＲ２を正常に受け付けることができなかったこと（即ちフェールとなったこと）を示すアップロードデータＵＤ２を車載端末２０から受信した場合には、対応するレコードを送信履歴情報Ｉｈから削除する。即ち、ビークルクラウドサーバ３０は、この場合、アップロードデータＵＤ２の送信元の車載端末２０に対応する車両ＩＤと、フェールとなったジョブを示すジョブＩＤと含むレコードを、送信履歴情報Ｉｈから削除する。これにより、送信履歴情報Ｉｈには、ジョブリクエストＪＲ２が正常に受け取った車載端末２０の車両ＩＤとジョブリクエストＪＲ２により指示されたジョブに対応するジョブＩＤとの組み合わせを示すレコードのみが記録されることになる。

ここで、図７に示す送信履歴情報Ｉｈの用途について説明する。ビークルクラウドサーバ３０は、送信履歴情報Ｉｈを参照することで、インアクティブになった車両数（「インアクティブ車両数」とも呼ぶ。）を好適に算出することが可能である。

具体的には、ビークルクラウドサーバ３０は、受信したジョブリクエストＪＲ１に対応するジョブＩＤが記録された送信履歴情報Ｉｈのレコード数を、ジョブリクエストＪＲ２を送信した車両数として計算する。ここで、図４に示したように、ジョブ状態は、認証処理が成功した場合には自動的にインアクティブ状態となるため、車載端末２０において認証処理が成功したジョブリクエストＪＲ２が示すジョブは、必ずインアクティブ状態となる。なお、認証処理が失敗してフェールとなった場合には、フェールとなった旨を示すアップロードデータＵＤ２がビークルクラウドサーバ３０に送信され、ビークルクラウドサーバ３０によって対応するレコードが送信履歴情報Ｉｈから削除される。よって、ビークルクラウドサーバ３０は、送信履歴情報Ｉｈを参照し、ジョブごとにジョブリクエストＪＲ２を送信した車両数をカウントすることで、当該ジョブが認証されて受け入れられた車両の数（インアクティブ車両数）をジョブごとに好適に特定することができる。なお、後述するように、特定したインアクティブ車両数の情報は、アップロードデータＵＤ１に含めてサービスクラウドサーバ４０に送信される。

（５－３）アップロードデータ
次に、アップロードデータＵＤ１、ＵＤ２のそれぞれのデータ構造について具体的に説明する。

図８は、車載端末２０がジョブリクエストＪＲ２に基づきビークルクラウドサーバ３０に対して送信するアップロードデータＵＤ２のデータ構造の一例である。図示のように、アップロードデータＵＤ２は、「バージョン情報」と、「リクエスト識別情報」と、「収集データ」と、「状態カウント情報」とを含む。

「バージョン情報」は、アップロードデータＵＤ２を規定した仕様のバージョン等を識別する情報である。この「バージョン情報」には、例えば、先に受信したジョブリクエストＪＲ２に含まれる「バージョン情報」と同一内容が指定される。「リクエスト識別情報」は、先に受信したジョブリクエストＪＲ２のリクエスト識別情報を示す。

「収集データ」は、先に受信したジョブリクエストＪＲ２に基づき車載端末２０が収集したデータであり、依頼されたジョブの実行結果に相当する。この収集データは、先に受信したジョブリクエストＪＲ２の「収集データ指定情報」により指定されたデータである。収集データは、「応答情報」の一例である。

「状態カウント情報」は、先に受信したジョブリクエストＪＲ２に基づき車載端末２０が記憶部２２に記憶した状態カウント情報であり、「アクティブ遷移回数」と、「インアクティブ遷移回数」とを含む。「アクティブ遷移回数」は、先に受信したジョブリクエストＪＲ２により依頼されたジョブの有効期間においてジョブがアクティブ状態へ遷移した回数（即ちアクティブ状態になった回数）を示す。「インアクティブ遷移回数」は、先に受信したジョブリクエストＪＲ２により依頼されたジョブの有効期間においてジョブがインアクティブ状態へ遷移した回数（即ちインアクティブ状態になった回数）を示す。状態カウント情報は、「回数情報」の一例である。

ここで、状態カウント情報の生成方法について補足説明する。

車載端末２０は、先に受信したジョブリクエストＪＲ２に有効な状態管理フラグＦｓが含まれる場合に、対象のジョブに対するアクティブ状態及びインアクティブ状態の各遷移回数のカウントを開始し、これらの遷移回数の情報を状態カウント情報として記憶部２２に記憶する。そして、車載端末２０は、状態カウント情報を、対象のジョブに対するジョブ状態の変更がある度に更新する。そして、車載端末２０は、アップロードデータＵＤ２の生成時に、記憶部２２に記憶した状態カウント情報をアップロードデータＵＤ２に含める。

図９は、ビークルクラウドサーバ３０がジョブリクエストＪＲ１に基づきサービスクラウドサーバ４０に対して送信するアップロードデータＵＤ１のデータ構造の一例である。図示のように、アップロードデータＵＤ２は、「バージョン情報」と、「リクエスト識別情報」と、「収集データ」と、「インアクティブ車両数」と、「アクティブ車両数」と、「アクティブ延べ車両数」と、「データ収集車両数」とを含む。

「バージョン情報」は、アップロードデータＵＤ１を規定した仕様のバージョン等を識別する情報である。この「バージョン情報」には、例えば、先に受信したジョブリクエストＪＲ１に含まれる「バージョン情報」と同一内容が指定される。「リクエスト識別情報」は、先に受信したジョブリクエストＪＲ１のリクエスト識別情報を示す。

「収集データ」は、ジョブリクエストＪＲ１により依頼されたジョブの実行結果に相当し、ジョブリクエストＪＲ１の「収集データ指定情報」により指定されたデータである。ビークルクラウドサーバ３０は、ジョブリクエストＪＲ１に基づき生成したジョブリクエストＪＲ２を複数の車載端末２０へ送信し、その応答であるアップロードデータＵＤ２を各車載端末２０から受信することで、「収集データ」としてアップロードデータＵＤ１に含めるデータを収集する。この場合、ビークルクラウドサーバ３０は、各車載端末２０から受信したアップロードデータＵＤ２に含まれる収集データをそのまま抽出したデータを「収集データ」としてアップロードデータＵＤ１に含めてもよく、各アップロードデータＵＤ２に含まれる収集データに対して所定の統計処理を行うことで算出した統計データを「収集データ」としてアップロードデータＵＤ１に含めてもよい。

「インアクティブ車両数」は、ジョブリクエストＪＲ１により依頼されたジョブの状態がインアクティブ状態となった車両数である。本実施例では、第１の例では、ビークルクラウドサーバ３０は、送信履歴情報Ｉｈを参照することで、ジョブリクエストＪＲ１により依頼されたジョブに対するインアクティブ車両数を算出する。具体的には、ビークルクラウドサーバ３０は、送信履歴情報Ｉｈに記録されたレコードのうち、ジョブリクエストＪＲ１により依頼されたジョブの識別情報（例えばリクエスト識別情報）が「ジョブＩＤ」として記録されたレコードの数を、インアクティブ車両数として算出する。上述したように、ジョブリクエストＪＲ２を受信した車載端末２０において、ジョブリクエストＪＲ２の認証が成功した場合、ジョブリクエストＪＲ２により依頼されたジョブの状態は必ずインアクティブ状態となり、かつ、ジョブリクエストＪＲ２の認証が失敗した場合には、当該ジョブリクエストＪＲ２の送信履歴に相当する送信履歴情報Ｉｈのレコードはビークルクラウドサーバ３０により削除される。よって、ビークルクラウドサーバ３０は、送信履歴情報Ｉｈを参照することで、ジョブリクエストＪＲ１により依頼されたジョブに対するインアクティブ車両数を好適に算出することができる。第２の例では、ビークルクラウドサーバ３０は、アップロードデータＵＤ２に含まれる状態カウント情報に基づき算出する。この場合、ビークルクラウドサーバ３０は、上述の状態カウント情報が示すインアクティブ遷移回数が１回以上となるアップロードデータＵＤ２の送信元の車載端末２０の数を、当該ジョブに対するインアクティブ車両数として算出する。

「アクティブ車両数」は、ジョブリクエストＪＲ１により依頼されたジョブの状態がアクティブ状態となった車両数である。本実施例では、ビークルクラウドサーバ３０は、ジョブリクエストＪＲ１に基づき生成したジョブリクエストＪＲ２の応答として各車載端末２０から受信したアップロードデータＵＤ２の状態カウント情報が示すアクティブ遷移回数を参照することで、ジョブリクエストＪＲ１により依頼されたジョブに対するアクティブ車両数を算出する。具体的には、ビークルクラウドサーバ３０は、当該ジョブのアクティブ遷移回数が１回以上となるアップロードデータＵＤ２を送信した車載端末２０の数を、当該ジョブのアクティブ車両数として算出する。このように、ビークルクラウドサーバ３０は、ジョブリクエストＪＲ２の送信先となる車載端末２０から受信したアップロードデータＵＤ２に含まれる状態カウント情報が示すアクティブ遷移回数を参照することで、ジョブリクエストＪＲ２により依頼されたジョブに対するアクティブ車両数を好適に算出することができる。

「アクティブ延べ車両数」は、ジョブリクエストＪＲ１により依頼されたジョブの状態がアクティブ状態となった延べ車両数である。本実施例では、ビークルクラウドサーバ３０は、ジョブリクエストＪＲ１に基づき生成したジョブリクエストＪＲ２の応答として各車載端末２０から受信したアップロードデータＵＤ２に含まれる状態カウント情報が示すアクティブ遷移回数を積算することで、ジョブリクエストＪＲ１により依頼されたジョブに対するアクティブ延べ車両数を算出する。このように、ビークルクラウドサーバ３０は、ジョブリクエストＪＲ２の送信先となる車載端末２０から受信したアップロードデータＵＤ２に含まれる状態カウント情報が示すアクティブ遷移回数を参照することで、ジョブリクエストＪＲ２により依頼されたジョブに対するアクティブ延べ車両数を好適に算出することができる。インアクティブ車両数、アクティブ車両数、及びアクティブ延べ車両数は、「移動体数情報」の一例である。

「データ収集車両数」は、ジョブリクエストＪＲ１により依頼されたジョブに対して収集データをアップロードした車両数である。本実施例では、ビークルクラウドサーバ３０は、ジョブリクエストＪＲ１に基づき生成したジョブリクエストＪＲ２の応答として各車載端末２０から受信したアップロードデータＵＤ２のうち、収集データが含まれていたアップロードデータＵＤ２の送信元の車両数を、データ収集車両数として算出する。

次に、アップロードデータＵＤ１の用途について補足説明する。

ジョブリクエストＪＲ１の応答として図９に示すようなデータ構造を有するアップロードデータＵＤ１を受信したサービスクラウドサーバ４０は、アップロードデータＵＤ１に含まれる各車両数の統計に基づき、返信された収集データの信頼性の判定、データ収集依頼の有効性やコスト効率の判定などを行うことができる。

例えば、サービスクラウドサーバ４０は、インアクティブ車両数に対するアクティブ車両数又は／及びデータ収集車両数の割合を示す割合情報を生成することで、ジョブリクエストＪＲ１に基づくデータ収集依頼の有効性やコスト効率を示す指標を好適に算出することができる。例えば、サービスクラウドサーバ４０は、上述の割合情報が示す割合が高いほど、データ収集依頼の有効性やコスト効率が高いと判定することができる。また、サービスクラウドサーバ４０は、アクティブ車両数、アクティブ延べ車両数、データ収集車両数などを参照することで、ビークルクラウドサーバ３０から受信したアップロードデータＵＤ１に含まれる収集データの信頼性を好適に判定することができる。例えば、サービスクラウドサーバ４０は、アクティブ車両数、アクティブ延べ車両数、及びデータ収集車両数が高いほど、ビークルクラウドサーバ３０から受信した収集データの信頼性が高いと判定することができる。

なお、アップロードデータＵＤ１のデータ構造例は、図９に示すものに限定されない。例えば、アップロードデータＵＤ１には、インアクティブ状態となった車両の延べ数を示すインアクティブ延べ車両数が含まれてもよい。この場合、ビークルクラウドサーバ３０は、各車載端末２０から受信したアップロードデータＵＤ１に含まれる状態カウント情報が示すインアクティブ遷移回数を積算することで、上述のインアクティブ延べ車両数を決定する。

（６）処理フロー
次に、有効な状態管理フラグＦｓを含むジョブリクエストＪＲ１及びジョブリクエストＪＲ２が生成された場合に車載端末２０及びビークルクラウドサーバ３０が実行する処理について、図１０及び図１１のフローチャートを参照して具体的に説明する。

（６－１）車載端末の処理
図１０は、有効な状態管理フラグＦｓが含まれるジョブリクエストＪＲ２を受信した場合に車載端末２０が実行する処理手順を示すフローチャートである。車載端末２０は、図１０に示すフローチャートの処理を繰り返し実行する。

まず、車載端末２０は、ビークルクラウドサーバ３０から有効な状態管理フラグＦｓを含むジョブリクエストＪＲ２を受信する（ステップＳ１０１）。そして、車載端末２０は、ジョブリクエストＪＲ２に対して所定の認証処理を行い、受信したジョブリクエストＪＲ２を認証できたか否か判定する（ステップＳ１０２）。

そして、車載端末２０は、受信したジョブリクエストＪＲ２の認証処理が成功した場合（ステップＳ１０２；Ｙｅｓ）、ジョブリクエストＪＲ２に有効な状態管理フラグＦｓが含まれていることから、ジョブリクエストＪＲ２に対する状態カウント情報を生成する（ステップＳ１０３）。ここで、ジョブリクエストＪＲ２の認証処理が成功した場合、車載端末２０は、ジョブ状態が自動的にインアクティブ状態となるため、アクティブ遷移回数を０、インアクティブ遷移回数を１とした状態カウント情報を生成する。

一方、車載端末２０は、受信したジョブリクエストＪＲ２の認証処理が失敗した場合（ステップＳ１０２；Ｎｏ）、認証が失敗した旨（即ちフェールとなった旨）のアップロードデータＵＤ２をビークルクラウドサーバ３０へ送信する（ステップＳ１１０）。

ステップＳ１０３で状態カウント情報の生成後、車載端末２０は、受信したジョブリクエストＪＲ２に含まれる「データ収集条件情報」が示すジョブの実行条件を満たすか否か判定する（ステップＳ１０４）。そして、車載端末２０は、ジョブの実行条件を満たすと判定した場合（ステップＳ１０４；Ｙｅｓ）、センサ部２７が出力するデータを用いて、ジョブリクエストＪＲ２に含まれる「収集データ指定情報」により指定されたデータの収集を行う（ステップＳ１０５）。この場合、ジョブのジョブ状態は、アクティブ状態となる。一方、車載端末２０は、ジョブの実行条件を満たさないと判定した場合（ステップＳ１０４；Ｎｏ）、ステップＳ１０５の処理を行うことなくステップＳ１０６へ移行する。この場合、ジョブのジョブ状態は、インアクティブ状態となる。

次に、車載端末２０は、ジョブ状態の遷移の有無に応じて状態カウント情報を更新する（ステップＳ１０６）。具体的には、車載端末２０は、ステップＳ１０４の判定処理に基づきジョブがインアクティブ状態からアクティブ状態へ遷移したと判定した場合には、当該ジョブに対するアクティブ遷移回数を１だけ増加させるように状態カウント情報を更新する。一方、車載端末２０は、ステップＳ１０４の判定処理に基づきジョブがアクティブ状態からインアクティブ状態へ遷移したと判定した場合には、当該ジョブに対するインアクティブ遷移回数を１だけ増加させるように状態カウント情報を更新する。

次に、車載端末２０は、アップロードデータＵＤ２の送信タイミングであるか否か判定する（ステップＳ１０７）。アップロードデータＵＤ２の送信タイミングは、種々の規則により定められてもよい。例えば、車載端末２０は、ジョブの有効期限の終了時に１度限りアップロードデータＵＤ２を送信するものであってもよく、ステップＳ１０５でデータ収集を行った都度アップロードデータＵＤ２を送信するものであってもよく、所定時間間隔ごとにアップロードデータＵＤ２を送信するものであってもよい。具体的なアップロードデータＵＤ２の送信タイミングは、例えば、ビークルクラウドサーバ３０から受信したジョブリクエストＪＲ２に含まれるデータ収集条件情報により指定されたタイミングに設定される。

そして、車載端末２０は、アップロードデータＵＤ２の送信タイミングである場合（ステップＳ１０７；Ｙｅｓ）、ステップＳ１０５で収集した収集データ及びインアクティブ遷移回数とアクティブ遷移回数とを示す状態カウント情報を含むアップロードデータＵＤ２（図８参照）をビークルクラウドサーバ３０へ送信する（ステップＳ１０８）。なお、車載端末２０は、アップロードデータＵＤ２を複数タイミングで送信する態様では、最後の送信タイミングで送信するアップロードデータＵＤ２にのみ状態カウント情報を含めてもよい。また、車載端末２０は、ジョブの有効期間における最終的なアクティブ遷移回数及びインアクティブ遷移回数をアップロードデータＵＤ２に含めるため、少なくともジョブの有効期限の終了時点での状態カウント情報を含むアップロードデータＵＤ２をビークルクラウドサーバ３０に送信してもよい。この場合のアップロードデータＵＤ２には、収集データが含まれなくともよい。即ち、この場合、車載端末２０は、収集データと状態カウント情報との送信タイミングを必ずしも一致させなくともよい。

次に、車載端末２０は、ジョブが終了したか否か判定する（ステップＳ１０９）。例えば、受信したジョブリクエストＪＲ２に含まれる「データ収集条件情報」にジョブの有効期限が示されている場合には、当該ジョブの有効期限が徒過したか否か判定する。そして、車載端末２０は、ジョブが終了したと判定した場合（ステップＳ１０９；Ｙｅｓ）、フローチャートの処理を終了する。一方、車載端末２０は、アップロードデータＵＤ２の送信タイミングではないと判定した場合（ステップＳ１０７；Ｎｏ）、または、ジョブが終了していないと判定した場合（ステップＳ１０９；Ｎｏ）、ステップＳ１０４へ処理を戻す。

（６－２）ビークルクラウドサーバの処理
図１１は、有効な状態管理フラグＦｓを含むジョブリクエストＪＲ１を受信したビークルクラウドサーバ３０が実行する処理手順を示すフローチャートを示す。

まず、ビークルクラウドサーバ３０は、有効な状態管理フラグＦｓを含むジョブリクエストＪＲ１をサービスクラウドサーバ４０から受信する（ステップＳ２０１）。そして、ビークルクラウドサーバ３０は、記憶部３２に記憶された車両情報を参照し、ビークルクラウドサーバ３０が管理する車両の車載端末２０に対して、ジョブリクエストＪＲ１に基づき生成したジョブリクエストＪＲ２を送信する（ステップＳ２０２）。

その後、ビークルクラウドサーバ３０は、ジョブリクエストＪＲ２の送信先である車載端末２０からアップロードデータＵＤ２を受信し、記憶部３２に記憶する（ステップＳ２０３）。そして、ビークルクラウドサーバ３０は、予め定めたアップロードデータＵＤ２の収集期間が終了するまで（ステップＳ２０４；Ｎｏ）、ステップＳ２０３においてアップロードデータＵＤ２の受信及び記憶を繰り返し行う。これにより、ビークルクラウドサーバ３０は、複数の車両の車載端末２０から供給されるアップロードデータＵＤ２を記憶する。

また、フローチャートに図示しない態様として、例えば、ある程度リアルタイム性が要求される情報などについては、ビークルクラウドサーバ３０は、アップロードデータＵＤ２の収集期間内において、定期的、あるいは断続的に受信したアップロードデータＵＤ２を記憶部３２に蓄積することなく、そのままサービスクラウドサーバ４０にアップロードデータＵＤ１として逐次送信するようにしてもよい。この場合、ビークルクラウドサーバ３０は、アップロードデータＵＤ２の収集期間終了後に、後述するステップＳ２０５で集計した状態カウント情報のみをサービスクラウドサーバ４０に送信する。

そして、ビークルクラウドサーバ３０は、アップロードデータＵＤ２の収集期間が終了したと判定した場合（ステップＳ２０４；Ｙｅｓ）、インアクティブ車両数、アクティブ車両数、アクティブ延べ車両数、データ収集車両数等の集計を行う（ステップＳ２０５）。例えば、ビークルクラウドサーバ３０は、アクティブ車両数及びアクティブ延べ車両数については、ステップＳ２０３で受信及び記憶したアップロードデータＵＤ２に含まれる状態カウント情報が示すアクティブ遷移回数に基づき算出する。また、ビークルクラウドサーバ３０は、インアクティブ車両数については、送信履歴情報Ｉｈ又は状態カウント情報が示すインアクティブ遷移回数のいずれかに基づき算出し、データ収集車両数については、収集データを含むアップロードデータＵＤ２の送信元の車載端末２０を数えることで算出する。なお、ビークルクラウドサーバ３０は、同一の車載端末２０から同一のジョブに関するアップロードデータＵＤ２を複数回受信していた場合には、最後に受信したアップロードデータＵＤ２に含まれる状態カウント情報に基づき、上述の集計を行うとよい。

次に、ビークルクラウドサーバ３０は、ステップＳ２０５での集計結果を含むアップロードデータＵＤ１（図９参照）を、ジョブリクエストＪＲ１の要求元であるサービスクラウドサーバ４０へ送信する（ステップＳ２０６）。その後、ジョブリクエストＪＲ１を生成したサービスクラウドサーバ４０は、ビークルクラウドサーバ３０からアップロードデータＵＤ１を受信する。この場合、サービスクラウドサーバ４０は、受信したアップロードデータＵＤ１に基づき、返信された収集データの信頼性の判定、データ収集依頼の有効性やコスト効率の判定などを行う。

（７）適用例
次に、本実施例の適用例について説明する。ここでは、市町村などの自治体が、街づくり・道路利用解析の一環として、渋滞情報や道路利用状況を詳細に把握するためにジョブ配信システムを利用する例について説明する。

図１２は、本適用例におけるジョブ配信システムの構成例を示す。図１２に示すジョブ配信システムは、地図会社が運営する第１サービスクラウドサーバ４０Ａと、自治体が運営する第１サービスクラウドサーバ４０Ａと、タクシー会社が運営するビークルクラウドサーバ３０と、車載端末２０が搭載されたタクシー車両Ｖとを有する。ここで、第１サービスクラウドサーバ４０Ａは、実施例のサービスクラウドサーバ４０として機能し、第２サービスクラウドサーバ４０Ｂは、第１サービスクラウドサーバ４０Ａが収集したデータを第１サービスクラウドサーバ４０Ａから受信するものとする。

自治体には２つの鉄道の駅（Ａ駅とＢ駅）があり、各駅前の通りが渋滞するので、駅前通りの拡充を必要とし、計画的に駅前通りを拡充するため、渋滞データを取得する。タクシー車両Ｖは、２つの鉄道駅の駅前通りを頻繁に走る車両であり、合計８０台存在する。また、各駅には、タクシープールが存在する。

図１３は、Ａ駅の駅前通りを示した俯瞰図である。図示のように、Ａ駅付近には、基幹道路５０と、基幹道路５０から分岐した駅前道路５１と、駅前道路５１に合流可能なタクシープール５２と、が存在する。駅前道路５１には、タクシープール５２へつながる交差点５３と、基幹道路５０への入り口となる交差点５４とが存在する。

ここで、第１サービスクラウドサーバ４０Ａは、図６に示す「収集データ指定情報」として、タクシープール５２から出て交差点５３から交差点５４までの駅前道路５１を通過する際の走行時間と滞留（停止）時間、及び、交差点５４からタクシープール５２に入るまでの走行時間と滞留時間を指定したジョブリクエストＪＲ１を生成する。このジョブリクエストＪＲ１には、次の月曜日から日曜日までの１週間をジョブの有効期限と定め、かつ、朝６時から夜７時までをジョブの実行時間帯と定めた「データ収集条件情報」（図６参照）をさらに含める。そして、第１サービスクラウドサーバ４０Ａは、ジョブリクエストＪＲ１の応答としてビークルクラウドサーバ３０から受信するアップロードデータＵＤ１に基づき、１０分間隔に区切られた各時間帯の平均走行時間及び平均滞留時間の算出を行う。そして、第１サービスクラウドサーバ４０Ａは、算出した平均走行時間及び平均滞留時間をアップロードデータとして第２サービスクラウドサーバ４０Ｂに送信する。この場合、第２サービスクラウドサーバ４０Ｂは、第１サービスクラウドサーバ４０Ａから受信したアップロードデータに基づき、渋滞情報の内容を吟味する。また、第１サービスクラウドサーバ４０Ａは、Ｂ駅に関しても同様に、ビークルクラウドサーバ３０から受信するアップロードデータＵＤ１に基づき、駅前道路に関する平均走行時間及び平均滞留時間の算出を行い、第２サービスクラウドサーバ４０Ｂへその算出結果を含むアップロードデータを送信する。

このような場合において、第１サービスクラウドサーバ４０Ａは、有効な状態管理フラグＦｓをジョブリクエストＪＲ１に含めることで、ジョブ状態等に関する車両数の統計データをビークルクラウドサーバ３０からアップロードデータＵＤ１により受信し、第２サービスクラウドサーバ４０Ｂに供給する。これにより、第２サービスクラウドサーバ４０Ｂは、各駅前の渋滞情報の内容を吟味する際に、ジョブ状態等に関する車両数の統計データを考慮することができるため、渋滞情報の的確な検討を行うことができる。また、測定車両数がない又は非常に少ない（即ちアクティブ車両数が非常に少ない）時間帯については、ひどい渋滞のためにタクシーの駅前道路への流入がない時間帯、又は、タクシーの需要がない時間帯（即ち多くのタクシー車両Ｖがタクシープールで待機した時間帯）だった可能性があると推測することも可能となる。自治体は、収集データ及び上述の車両数の統計データに基づき、タクシー会社等と必要に応じて協議を行い、渋滞情報の取得条件と解析方法などについて調整を行う。

＜第２実施例＞
第２実施例に係る車載端末２０は、各ジョブ状態への遷移回数を示す状態カウント情報をビークルクラウドサーバ３０へ送信する代わりに、ジョブ状態の遷移に関する履歴情報（「状態履歴情報」とも呼ぶ。）をビークルクラウドサーバ３０へ送信する。以後では、ビークルクラウドサーバ３０及びサービスクラウドサーバ４０の構成、ジョブリクエストＪＲ１、ＪＲ２のデータ構造、アップロードデータＵＤ１のデータ構造等については、第１実施例と同一であるため、その説明を省略する。

図１４は、第２実施例に係る車載端末２０の内部構成を示すブロック図である。図示のように、車載端末２０の記憶部２２は、状態履歴情報を記憶している。状態履歴情報は、ジョブリクエストＪＲ２により依頼されたジョブが有効な期間における当該ジョブの状態遷移の履歴情報である。状態履歴情報は、例えば、ジョブが遷移した状態と、遷移した時刻とを、依頼されたジョブごとに（例えばリクエスト識別情報ごとに）関連付けたテーブル情報である。車載端末２０は、有効な状態管理フラグＦｓが先に受信したジョブリクエストＪＲ２に含まれる場合に、対象のジョブに対するジョブ状態の遷移を状態履歴情報として記憶部２２に記憶する。

図１５は、第２実施例に係るアップロードデータＵＤ２のデータ構造の一例である。図１５に示すように、第２実施例に係るアップロードデータＵＤ２は、状態カウント情報に代えて、「状態履歴情報」を含んでいる。車載端末２０は、有効な状態管理フラグＦｓが対応するジョブリクエストＪＲ２に含まれていた場合に、当該ジョブリクエストＪＲ２により依頼されたジョブの実行結果である収集データと共に、当該ジョブに対応する状態履歴情報を、アップロードデータＵＤ２に含めてビークルクラウドサーバ３０に送信する。これにより、アップロードデータＵＤ２を受信したビークルクラウドサーバ３０は、状態履歴情報を参照することで、アップロードデータＵＤ２の送信元の車載端末２０のインアクティブ遷移回数及びアクティブ遷移回数を好適に算出することが可能となる。状態履歴情報は、「計数情報」の一例である。

図１６は、有効な状態管理フラグＦｓが含まれるジョブリクエストＪＲ２を受信した場合に第２実施例に係る車載端末２０が実行する処理手順を示すフローチャートである。車載端末２０は、図１６に示すフローチャートの処理を繰り返し実行する。

車載端末２０は、ビークルクラウドサーバ３０から有効な状態管理フラグＦｓを含むジョブリクエストＪＲ２を受信し（ステップＳ３０１）、受信したジョブリクエストＪＲ２の認証処理が成功した場合（ステップＳ３０２；Ｙｅｓ）、ジョブリクエストＪＲ２により依頼されたジョブに対する状態履歴情報を生成する（ステップＳ３０３）。この場合、ジョブ状態が自動的にインアクティブ状態となるため、車載端末２０は、インアクティブ状態への遷移を記録した状態履歴情報を生成する。

そして、車載端末２０は、受信したジョブリクエストＪＲ２に含まれる「データ収集条件情報」が示すジョブの実行条件を満たす場合（ステップＳ３０４；Ｙｅｓ）、センサ部２７が出力するデータを用いて、ジョブリクエストＪＲ２に含まれる「収集データ指定情報」により指定されたデータの収集を行う（ステップＳ３０５）。この場合、ジョブのジョブ状態は、アクティブ状態となる。一方、車載端末２０は、ジョブの実行条件を満たさないと判定した場合（ステップＳ３０４；Ｎｏ）、ステップＳ３０５の処理を行うことなくステップＳ３０６へ移行する。この場合、ジョブのジョブ状態は、インアクティブ状態となる。

次に、車載端末２０は、ジョブ状態の遷移の有無に応じて状態履歴情報を更新する（ステップＳ３０６）。具体的には、車載端末２０は、状態履歴情報が示す最新のジョブ状態と比較し、現在のジョブ状態がインアクティブ状態からアクティブ状態へ遷移していると判定した場合には、アクティブ状態への遷移を示すレコードを、対象のジョブに対する状態履歴情報に追加し、アクティブ状態からインアクティブ状態へ遷移していると判定した場合には、インアクティブ状態への遷移を示すレコードを、対象のジョブに対する状態履歴情報に追加する。

その後、第１実施例と同様に、車載端末２０は、アップロードデータＵＤ２の送信タイミングである場合（ステップＳ３０７；Ｙｅｓ）、ステップＳ３０５で収集した収集データ及び状態履歴情報を含むアップロードデータＵＤ２（図１５参照）をビークルクラウドサーバ３０へ送信する（ステップＳ３０８）。また、車載端末２０は、ジョブが終了したと判定した場合（ステップＳ３０９；Ｙｅｓ）、フローチャートの処理を終了する。一方、アップロードデータＵＤ２の送信タイミングでない場合（ステップＳ３０７；Ｎｏ）、又は、ジョブが終了していない場合（ステップＳ３０９；Ｎｏ）、ステップＳ３０４へ処理を戻す。

図１７は、有効な状態管理フラグＦｓを含むジョブリクエストＪＲ１を受信した第２実施例に係るビークルクラウドサーバ３０が実行する処理手順を示すフローチャートを示す。

まず、ビークルクラウドサーバ３０は、有効な状態管理フラグＦｓを含むジョブリクエストＪＲ１をサービスクラウドサーバ４０から受信する（ステップＳ４０１）。そして、ビークルクラウドサーバ３０は、記憶部３２に記憶された車両情報を参照し、ビークルクラウドサーバ３０が管理する車両の車載端末２０に対して、ジョブリクエストＪＲ１に基づき生成したジョブリクエストＪＲ２を送信する（ステップＳ４０２）。

その後、ビークルクラウドサーバ３０は、状態履歴情報を含むアップロードデータＵＤ２を車載端末２０から受信し、記憶部３２に記憶する（ステップＳ４０３）。そして、ビークルクラウドサーバ３０は、予め定めたアップロードデータＵＤ２の収集期間が終了するまで（ステップＳ４０４；Ｎｏ）、ステップＳ４０３においてアップロードデータＵＤ２の受信及び記憶を繰り返し行う。

そして、ビークルクラウドサーバ３０は、アップロードデータＵＤ２の収集期間が終了したと判定した場合（ステップＳ４０４；Ｙｅｓ）、ステップＳ４０３で受信及び記憶したアップロードデータＵＤ２に含まれる状態履歴情報に基づき、車両ごとのアクティブ遷移回数などを算出する（ステップＳ４０５）。この場合、ビークルクラウドサーバ３０は、アクティブ遷移回数に加えて、インアクティブ遷移回数などについても状態履歴情報に基づき算出してもよい。なお、ビークルクラウドサーバ３０は、同一の車載端末２０から同一のジョブに関するアップロードデータＵＤ２を複数回受信していた場合には、最後に受信したアップロードデータＵＤ２に含まれる状態履歴情報に基づき、上述の算出を行うとよい。

そして、ビークルクラウドサーバ３０は、インアクティブ車両数、アクティブ車両数、アクティブ延べ車両数、データ収集車両数等の集計を行う（ステップＳ４０６）。例えば、ビークルクラウドサーバ３０は、アクティブ車両数及びアクティブ延べ車両数については、ステップＳ４０５で算出した車両ごとのアクティブ遷移回数に基づき算出する。また、ビークルクラウドサーバ３０は、インアクティブ車両数については、送信履歴情報Ｉｈ又はステップＳ４０５で算出したインアクティブ遷移回数のいずれかに基づき算出し、データ収集車両数については、収集データを含むアップロードデータＵＤ２の送信元の車載端末２０を数えることで算出する。

次に、ビークルクラウドサーバ３０は、ステップＳ４０５での集計結果を含むアップロードデータＵＤ１（図９参照）を、ジョブリクエストＪＲ１の要求元であるサービスクラウドサーバ４０へ送信する（ステップＳ４０７）。その後、ジョブリクエストＪＲ１を生成したサービスクラウドサーバ４０は、ビークルクラウドサーバ３０からアップロードデータＵＤ１を受信する。この場合、サービスクラウドサーバ４０は、受信したアップロードデータＵＤ１に基づき、返信された収集データの信頼性の判定、データ収集依頼の有効性やコスト効率の判定などを行う。

＜第３実施例＞
第３実施例に係る車載端末２０は、状態カウント情報又は状態履歴情報に代えて、現在のジョブ状態を示す情報（単に「状態情報」とも呼ぶ。）をビークルクラウドサーバ３０へ送信する。以後では、サービスクラウドサーバ４０の構成、ジョブリクエストＪＲ１、ＪＲ２のデータ構造、アップロードデータＵＤ１のデータ構造等については、第１及び第２実施例と同一であるため、その説明を省略する。

図１８は、第３実施例に係るアップロードデータＵＤ２のデータ構造の一例である。図１８に示すように、第３実施例に係るアップロードデータＵＤ２は、第１実施例の状態カウント情報又は第２実施例の状態履歴情報に代えて、「状態情報」を含んでいる。

車載端末２０は、有効な状態管理フラグＦｓがジョブリクエストＪＲ２に含まれていた場合に、当該ジョブリクエストＪＲ２により依頼されたジョブの実行結果である収集データと共に、当該ジョブに対応する現在のジョブ状態を示す状態情報を、アップロードデータＵＤ２に含めてビークルクラウドサーバ３０に送信する。この場合、車載端末２０は、ビークルクラウドサーバ３０から受信したジョブリクエストＪＲ２に含まれるデータ収集条件情報により指定された時間間隔によりアップロードデータＵＤ２をビークルクラウドサーバ３０へ送信する。なお、この場合のアップロードデータＵＤ２の送信タイミングは、ジョブごとに定められてもよく、複数のジョブで一律であってもよい。状態情報は、「計数情報」の一例である。

図１９は、第３実施例に係るビークルクラウドサーバ３０の内部構成を概略的に示した図である。図１９に示すように、ビークルクラウドサーバ３０は、状態履歴情報を記憶部３２に記憶している。ここで、ビークルクラウドサーバ３０は、例えば、状態履歴情報を、車載端末２０から受信するアップロードデータＵＤ２に含まれる状態情報に基づき、ジョブごと及び車両ＩＤごとに生成する。この場合、例えば、状態履歴情報は、リクエスト識別情報及び車両ＩＤごとに、状態情報が示すジョブ状態と、状態情報の受信時刻又は生成時刻とを関連付けた情報である。ビークルクラウドサーバ３０は、このような状態履歴情報を保持することで、第１実施例及び第２実施例と同様、インアクティブ車両数、アクティブ車両数、アクティブ延べ車両数、データ収集車両数等の集計を好適に行うことができる。

図２０は、有効な状態管理フラグＦｓが含まれるジョブリクエストＪＲ２を受信した場合に第３実施例に係る車載端末２０が実行する処理手順を示すフローチャートである。車載端末２０は、図２０に示すフローチャートの処理を繰り返し実行する。

車載端末２０は、ビークルクラウドサーバ３０から有効な状態管理フラグＦｓを含むジョブリクエストＪＲ２を受信し（ステップＳ５０１）、受信したジョブリクエストＪＲ２の認証処理が成功した場合（ステップＳ５０２；Ｙｅｓ）、受信したジョブリクエストＪＲ２が示すジョブの実行条件を満たすか否か判定する（ステップＳ５０３）。そして、ジョブの実行条件を満たす場合（ステップＳ５０３；Ｙｅｓ）、センサ部２７が出力するデータを用いて、ジョブリクエストＪＲ２により指定されたデータの収集を行う（ステップＳ５０４）。一方、車載端末２０は、ジョブの実行条件を満たさないと判定した場合（ステップＳ５０３；Ｎｏ）、ステップＳ５０４の処理を行うことなくステップＳ５０５へ移行する。

次に、車載端末２０は、アップロードデータＵＤ２の送信タイミングであるか否か判定する（ステップＳ５０５）。この場合のアップロードデータＵＤ２の送信タイミングは、ジョブごとに定められてもよく、複数のジョブで一律であってもよい。そして、車載端末２０は、アップロードデータＵＤ２の送信タイミングである場合（ステップＳ５０５；Ｙｅｓ）、現在のジョブ状態を示す状態情報を生成する（ステップＳ５０５）。具体的には、車載端末２０は、ジョブの実行条件を満たしていない場合には、当該ジョブがインアクティブ状態であることを示す状態情報を生成し、ジョブの実行条件を満たしている場合には、当該ジョブがアクティブ状態であることを示す状態情報を生成する。

そして、車載端末２０は、ステップＳ５０６で生成した状態情報と、ステップＳ５０４で収集した収集データとを含むアップロードデータＵＤ２をビークルクラウドサーバ３０に送信する（ステップＳ５０７）。そして、車載端末２０は、ジョブを終了すべきと判定した場合（ステップＳ５０８；Ｙｅｓ）、フローチャートの処理を終了する。

一方、車載端末２０は、アップロードデータＵＤ２の送信タイミングでない場合（ステップＳ５０５；Ｎｏ）、又は、ジョブが終了していない場合（ステップＳ５０８；Ｎｏ）、ステップＳ５０３へ処理を戻す。これにより、車載端末２０は、ステップＳ５０３～ステップＳ５０７の処理を、ジョブの有効期限が終了するまで繰り返し実行する。

図２１は、有効な状態管理フラグＦｓを含むジョブリクエストＪＲ１を受信した第３実施例に係るビークルクラウドサーバ３０が実行する処理手順を示すフローチャートを示す。

まず、ビークルクラウドサーバ３０は、有効な状態管理フラグＦｓを含むジョブリクエストＪＲ１をサービスクラウドサーバ４０から受信する（ステップＳ６０１）。そして、ビークルクラウドサーバ３０は、記憶部３２に記憶された車両情報を参照し、ビークルクラウドサーバ３０が管理する車両の車載端末２０に対して、ジョブリクエストＪＲ１に基づき生成したジョブリクエストＪＲ２を送信する（ステップＳ６０２）。

その後、ビークルクラウドサーバ３０は、状態情報を含むアップロードデータＵＤ２を車載端末２０から受信し、記憶部３２に記憶する（ステップＳ６０３）。そして、ビークルクラウドサーバ３０は、受信したアップロードデータＵＤ２が示すジョブ及び車両ＩＤに対応する状態履歴情報を更新する（ステップＳ６０４）。例えば、ビークルクラウドサーバ３０は、対象の状態履歴情報に対し、受信したアップロードデータＵＤ２の状態情報が示すジョブ状態と、時刻情報とを含むレコードを追加する。そして、ビークルクラウドサーバ３０は、予め定めたアップロードデータＵＤ２の収集期間が終了するまで（ステップＳ６０５；Ｎｏ）、ステップＳ６０３及びステップＳ６０４を繰り返し行う。

そして、ビークルクラウドサーバ３０は、アップロードデータＵＤ２の収集期間が終了したと判定した場合（ステップＳ６０５；Ｙｅｓ）、記憶部３２に記憶した状態履歴情報に基づき、車両ごとのアクティブ遷移回数などを算出する（ステップＳ６０６）。この場合、ビークルクラウドサーバ３０は、アクティブ遷移回数に加えて、インアクティブ遷移回数などについても状態履歴情報に基づき算出してもよい。

そして、ビークルクラウドサーバ３０は、インアクティブ車両数、アクティブ車両数、アクティブ延べ車両数、データ収集車両数等の集計を行う（ステップＳ６０７）。例えば、ビークルクラウドサーバ３０は、アクティブ車両数及びアクティブ延べ車両数については、ステップＳ６０５で算出した車両ごとのアクティブ遷移回数に基づき算出する。また、ビークルクラウドサーバ３０は、インアクティブ車両数については、送信履歴情報Ｉｈ又はステップＳ６０５で算出したインアクティブ遷移回数のいずれかに基づき算出し、データ収集車両数については、収集データを含むアップロードデータＵＤ２の送信元の車載端末２０を数えることで算出する。

次に、ビークルクラウドサーバ３０は、ステップＳ６０５での集計結果を含むアップロードデータＵＤ１（図９参照）を、ジョブリクエストＪＲ１の要求元であるサービスクラウドサーバ４０へ送信する（ステップＳ６０８）。その後、ジョブリクエストＪＲ１を生成したサービスクラウドサーバ４０は、ビークルクラウドサーバ３０からアップロードデータＵＤ１を受信する。この場合、サービスクラウドサーバ４０は、受信したアップロードデータＵＤ１に基づき、返信された収集データの信頼性の判定、データ収集依頼の有効性やコスト効率の判定などを行う。

以上説明したように、ビークルクラウドサーバ３０は、サービスクラウドサーバ４０が発したジョブリクエストＪＲ１を受信し、複数の車両の車載端末２０に対してジョブリクエストＪＲ１に応じたジョブリクエストＪＲ２を送信する。また、ビークルクラウドサーバ３０は、複数の車両の車載端末２０が正常にジョブリクエストＪＲ２を受信できたことを示す受信結果であるアップロードデータＵＤ２を受信し、アップロードデータＵＤ２に基づき、ジョブリクエストＪＲ２を正常に受信できた車両数であるインアクティブ車両数を計数する。また、ビークルクラウドサーバ３０は、ジョブのアクティブ遷移回数が１回以上となるアップロードデータＵＤ２を受信し、当該アップロードデータＵＤ２を送信した車両数及び延べ車両数を表すアクティプ車両数及びアクティブ延べ車両数を計数する。そして、ビークルクラウドサーバ３０は、インアクティブ車両数、アクティプ車両数、アクティブ延べ車両数の情報を含むアップロードデータＵＤ１をサービスクラウドサーバ４０へ送信する。

以上説明したように、ビークルクラウドサーバ３０は、サービスクラウドサーバ４０が発したジョブリクエストＪＲ１を受信する。そして、ビークルクラウドサーバ３０は、ジョブリクエストＪＲ１に応じたデータ収集条件情報及び収集データ指定情報と、データ収集条件情報及び収集データ指定情報が示すジョブの状態が、所定条件が満たされた場合に当該ジョブを実行する状態であるアクティブ状態になった回数であるアクティブ遷移回数を計数するための状態カウント情報又は状態履歴情報若しくは状態情報を送信することを示す状態管理フラグＦｓと、を含むジョブリクエストＪＲ２を生成する。そして、ビークルクラウドサーバ３０は、複数の車両の車載端末２０に対してジョブリクエストＪＲ２を送信する。そして、ビークルクラウドサーバ３０は、ジョブリクエストＪＲ２に対する収集データと状態カウント情報又は状態履歴情報若しくは状態情報とを含むアップロードデータＵＤ２を受信し、状態カウント情報又は状態履歴情報若しくは状態情報に基づき、アクティプ車両数又はアクティブ延べ車両数の少なくとも一方を計数する。そして、ビークルクラウドサーバ３０は、上述の計数結果に基づくアップロードデータＵＤ１をサービスクラウドサーバ４０に送信する。

＜変形例＞
次に、上述の第１～第３実施例に好適な変形例について説明する。以下の変形例は、任意に組み合わせて上述の実施例に適用してもよい。

（変形例１）
第１～第３実施例において、車載端末２０に相当する機能が車両Ｖに内蔵されていてもよい。この場合、車両の電子制御装置（ＥＣＵ：Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）は、車両のメモリに記憶されたプログラムを実行することで、車載端末２０の制御部２４に相当する処理を実行する。この場合、車両Ｖは、「移動体」の一例であり、車両Ｖの電子制御装置は、「端末装置」の一例である。

（変形例２）
第１実施例の状態カウント情報には、インアクティブ遷移回数に関する情報が含まれていた。これに代えて、状態カウント情報には、インアクティブ遷移回数に関する情報が含まれていなくともよい。

この場合、車載端末２０は、図１０のステップＳ１０３及びステップＳ１０６において、アクティブ遷移回数のみをカウントし、カウントしたアクティブ遷移回数の情報をアップロードデータＵＤ２に含めてビークルクラウドサーバ３０に送信する。この場合、ビークルクラウドサーバ３０は、図１１のステップＳ２０５において、インアクティブ車両数を、送信履歴情報Ｉｈに基づき算出する。また、ビークルクラウドサーバ３０は、アップロードデータＵＤ２の送信元となる車載端末２０の数をカウントすることで、データ収集車両数を算出する。

同様に、第２実施例の状態履歴情報には、インアクティブ状態への遷移に関する情報が含まれていなくともよい。この場合においても、状態履歴情報を含むアップロードデータＵＤ２を受信したビークルクラウドサーバ３０は、図１７のステップＳ４０６において、インアクティブ車両数を、送信履歴情報Ｉｈに基づき算出すればよい。

（変形例３）
第１実施例において、車載端末２０は、アップロードデータＵＤ２の送信時に状態履歴情報から状態カウント情報を生成し、アップロードデータＵＤ２に状態カウント情報を含めてもよい。この場合、車載端末２０は、図１４と同様、記憶部２２に状態履歴情報を記憶する。そして、車載端末２０は、アップロードデータＵＤ２の送信タイミングにおいて、記憶部２２に記憶した状態履歴情報を参照して状態カウント情報を生成し、収集データ等と共にアップロードデータＵＤ２としてビークルクラウドサーバ３０へ送信する。

（変形例４）
第１～第３実施例において、ジョブリクエストＪＲ１、ＪＲ２に含まれるジョブは複数であってもよい。この場合、複数のジョブに共通の実行条件が設定されていてもよく、ジョブごとに異なる実行条件が設定されていてもよい。ジョブごとに異なる実行条件が設定されている場合、ジョブは個々のジョブ状態を持つ。例えば、インアクティブ状態からアクティブ状態への遷移は、実行条件を満たしたジョブが個別にアクティブ状態に遷移する。

（変形例５）
第１～第３実施例において、ビークルクラウドサーバ３０は、インアクティブ車両数に対するアクティブ車両数の割合、又は、インアクティブ車両数に対するデータ収集車両数の割合等を示す割合情報を生成し、当該割合情報をアップロードデータＵＤ１に含めてサービスクラウドサーバ４０へ送信してもよい。これにより、ビークルクラウドサーバ３０は、データ収集依頼の有効性やコスト効率を判定するのに必要な情報をサービスクラウドサーバ４０に対して好適に送信することができる。本変形例において、上述の割合情報は、「移動体数情報」の一例である。

２０ 車載端末
２７ センサ部
３０ ビークルクラウドサーバ
４０ サービスクラウドサーバ

Claims (1)

1. 情報管理装置が発した要求信号を受信する第１受信部と、
   前記要求信号に応じた指令情報を生成する生成部と、
   複数の移動体に対して前記指令情報を送信する第１送信部と、
   前記複数の移動体が正常に前記指令情報を受信できたことを示す受信結果を受信する第２受信部と、
   前記受信結果に基づき、前記指令情報を正常に受信できた移動体の数を計数する第１計数部と、
   前記指令情報に対する応答情報を受信する第３受信部と、
   前記正常に受信できた移動体の数を前記情報管理装置に送信する第２送信部と、
   を備えることを特徴とする移動体管理装置。