説明

車両情報処理方法および車両情報処理サーバ

【課題】優先的に運転診断すべき、ユーザからの診断結果の要求の発生を推定する。
【解決手段】本発明の車両情報処理システムは、車両から車両情報を受信し、車両の運転診断の診断結果を送信するデータ送受信部、データ送受信部により、診断結果を車両へ送信した提供履歴を格納する提供履歴管理部、提供履歴管理部に格納される診断結果の提供履歴から利用傾向を求める利用傾向判定部、受信した車両情報から車両の走行状態を求める走行状態判定部、求めた利用傾向と走行状態とに応じた優先度に基づいて、車両情報を用いて車両を運転診断する運転診断部、及び、運転診断部による運転診断の診断結果を、データ送受信部を用いて送信する診断結果提供部を有する。

【発明の詳細な説明】
【技術分野】
【0001】
本発明は、車両情報処理方法および車両情報処理サーバに係り、特に車両からアップロードされる車両情報に基づいて、運転診断する順序を決定する技術に係わる。
【背景技術】
【0002】
自動車に取り付けた車載端末とセンタサーバとを無線ネットワークで接続し、渋滞情報や音楽コンテンツなどの配信を行うテレマティクスサービスが注目されている。センタのコンテンツをダウンロードするだけでなく、車載端末で収集した車両情報をアップロードし、アップロードした車両情報でエコ運転診断や安全運転診断を行うテレマティクスサービスも注目されてきている。エコ運転診断や安全運転診断の結果を車載端末へ提供するテレマティクスサービスでは、自動車からセンタサーバへアップロードされる車両情報を迅速に診断、車載端末からの診断結果の要求に応答しなければならない。また、ドライバが診断結果に基づいて運転を改善するためには、運転と診断結果の対応をドライバが理解しやすい形で診断結果を提供しなければならない。
【0003】
ユーザであるドライバからの要求に対する応答性能を確保したまま、莫大な量の情報を処理するための方法の一つとして、ユーザ毎に事前に優先度を決めておき、そのユーザのリクエストを優先的に処理する方法がある。例えば、特許文献1(特開2003−216583)に開示されているように、一台のwwwサーバ装置において一時的な利用者からのリクエストメッセージの集中による処理負荷を吸収するためにリクエストメッセージに対するキューを用い、特定のユーザのリクエストメッセージを優先して処理を行うことで、応答性能を保証したサービスを提供する。また、他の優先制御に関する技術として、情報に優先度をつけ、優先度の高い情報から処理する方法がある。例えば、特許文献2(特開2009−20662)に開示されているように、配信制御情報に優先度を含むことで、情報提供判定装置が登録する配信制御情報を用いて、情報配信制御装置の配信順序を動的に変更することができる。
【先行技術文献】
【特許文献】
【0004】
【特許文献1】特開2003−216583
【特許文献2】特開2009−20662
【発明の概要】
【発明が解決しようとする課題】
【0005】
センタサーバを用いた車両情報処理システムのサービス対象の自動車の数が莫大なため、それらの全ての車両情報を対象に運転診断するには時間がかかる。そのため、車両情報処理システムが効率的に運転診断するためには、診断結果の要求の発生を推定し、その要求に対応する車両情報を対象に優先的に運転診断する必要がある。診断結果の要求の発生を推定するためには、要求しやすい状況(場所など)、要求しやすい人(ユーザ)を判定する必要がある。
【0006】
これに対して特許文献1では、ユーザ毎に設定した優先度に応じて運転診断を優先制御している。ユーザであるドライバは必要に応じて診断結果を要求するので、診断結果の要求頻度などの要求状況は変化し、設定した固定的な優先度では対応できない。
【0007】
特許文献2では、配信制御情報に設定した優先度に基づいて配信制御しているが、優先度の決定方法は考慮されていないので、要求状況の変化に対応できない。
【課題を解決するための手段】
【0008】
開示された車両情報処理方法および車両情報処理サーバは、車両から車両情報を受信し、車両の運転診断の診断結果を送信するデータ送受信部、データ送受信部により、診断結果を車両へ送信した提供履歴を格納する提供履歴管理部、提供履歴管理部に格納される診断結果の提供履歴から利用傾向を求める利用傾向判定部、受信した車両情報から車両の走行状態を求める走行状態判定部、求めた利用傾向と走行状態とに応じた優先度に基づいて、車両情報を用いて車両を運転診断する運転診断部、及び、運転診断部による運転診断の診断結果を、データ送受信部を用いて送信する診断結果提供部を有する車両情報処理サーバにより具現化される。
【0009】
車両情報処理方法および車両情報処理システムの、他の望ましい態様によれば、利用傾向判定部が求める利用傾向は、車両が前記診断結果を要求する、「候補地点」、「候補曜日」及び「候補時間帯」、並びに、提供履歴に含まれる診断結果を提供した、「回数」及び「間隔」である。
【0010】
車両情報処理方法および車両情報処理システムの、さらに他の望ましい態様によれば、「候補地点」、「候補曜日」及び「候補時間帯」は、提供履歴の中で、前記診断結果を提供した回数および比率の少なくとも一方の値が他に比べて高い、場所、曜日及び時間帯である。
【0011】
車両情報処理方法および車両情報処理システムの、さらに他の望ましい態様によれば、利用傾向部は、提供履歴管理部に格納される、少なくとも直近の所定期間分を含む提供履歴から求める。
【0012】
車両情報処理方法および車両情報処理システムの、さらに他の望ましい態様によれば、走行状態判定部が求める走行状態は、車両の位置と特定地点との位置関係として、「前記車両が特定地点へ接近中か否か」及び「車両が特定地点の近辺を走行中か否か」である。
【0013】
車両情報処理方法および車両情報処理システムの、さらに他の望ましい態様によれば、特定地点は、車両へ搭載された機器に登録され、データ送受信部が受信する車両情報に含まれる場所、及び、提供履歴の中で、診断結果を提供した回数および比率の少なくとも一方の値が他に比べて高い場所の何れかである。
【0014】
車両情報処理方法および車両情報処理システムの、さらに他の望ましい態様によれば、診断結果提供部は、診断結果の送信に対応して、診断結果を提供したログを、提供履歴管理部に格納される診断結果の提供履歴として追加する。
【発明の効果】
【0015】
本発明によれば、ユーザからの診断結果の要求の発生を推定し、その要求に対応する車両情報を対象に優先的に運転診断できる。
【図面の簡単な説明】
【0016】
【図1】本実施形態の車両情報処理システムの構成図を示す。
【図2】本実施形態の車載端末のハードウェア構成図を示す。
【図3】本実施形態の車両情報蓄積部のテーブル構成を示す。
【図4】本実施形態の認証情報管理部のテーブル構成を示す。
【図5】本実施形態の車両情報管理部のテーブル構成を示す。
【図6】本実施形態のルール管理部のテーブル構成を示す。
【図7】本実施形態の診断結果管理部のテーブル構成を示す。
【図8】本実施形態の提供履歴管理部のテーブル構成を示す。
【図9】本実施形態の優先度に応じた運転診断処理のフローを示す。
【図10】本実施形態のドライバへのコンテンツ提供のシーケンスを示す。
【図11】本実施形態のコンテンツ生成部の処理フローを示す。
【図12A】本実施形態のドライバへ提供する、ディスプレイの画面例を示す。
【図12B】本実施形態のドライバへ提供する、ディスプレイの画面例を示す。
【発明を実施するための形態】
【0017】
以下に、本発明の実施形態について、図を用いて詳細に説明する。図1は、本実施形態における車両情報処理システムの構成図を示す。車両101には、車載端末102、通信装置109、車内ネットワーク110、ECU111、GPS112、ナビゲーション装置113、ディスプレイ114、入力装置115が搭載される。ECU111はElectric Control Unit(電子制御装置)で、車両101の走行を制御する装置である。車載端末102とECU111とは、車内ネットワーク110で接続されており、車載端末102は、車内ネットワーク110を介して、車両101の走行速度(以下、車速)や燃料噴射量のような、ECU111が制御に使用している情報(制御対象に対する制御情報と制御対象の状態情報)を車両情報として取得する。車載端末102は、GPS112から位置情報や時刻情報を、ナビゲーション装置113から自宅や会社、目的地などの地点情報を取得する。
【0018】
本実施形態では車両情報の取得先としてECU111、GPS112、ナビゲーション装置113を説明するが、必要に応じて各種センサなども、車内ネットワーク110を介して、または直接接続して車両情報の取得先とする。車載端末102は、ディスプレイ114や入力装置115と専用線で接続される。車載端末102は通信装置109と接続され、ネットワーク119を介してセンタサーバ120とデータを送受信する。通信装置109は、車両101に組込みの通信モジュールでも良いし、外付けで接続された携帯電話などでも良い。
【0019】
以下に説明する各処理は、車載端末102が有するCPUによりプログラムを実行することで実現される。車載端末102は、車両情報収集部103、データ送受信部105、コンテンツ生成部106および診断結果取得部107の各処理を実行する。車載端末102は、車両情報収集部103で収集した車両情報を格納する車両情報蓄積部104を有する。車両情報収集部103は、1秒間隔などの周期で、GPS112からの車両101の現在位置や現在時刻、車内ネットワーク110を介したECU111からの車速などの情報、及びナビゲーション装置113からの自宅、会社、目的地などの地点情報の各情報を取得し、車両情報蓄積部104に格納する。
【0020】
データ送受信部105は、センタサーバ120のデータ送受信部121と通信してデータを送受信する。データ送受信部105は、10分周期など、定期的にネットワーク119を介した回線を接続して車両情報蓄積部104に蓄積されたデータを送信する。このとき、車載端末102に事前に割当てられている車載端末固有のID(識別子)である車載機IDを併せてセンタサーバ120へ送信する。車両101からデータを送信するタイミングは、定期的ではなく、ユーザからの入力装置115を介したトリガーによるタイミング(通信接続の機会)でも良いし、ユーザがセンタサーバ120から情報を取得するタイミングでデータを送信しても良い。車両情報蓄積部104に格納されている未アップロード情報(未だセンタサーバ120へ送信していない情報)の全てを一回の通信接続(ネットワーク119を介した回線の接続)で送信しても良いし、一回の通信接続で送信するデータサイズの上限を設定するようにしても良い。
【0021】
ユーザが運転診断の結果を含むコンテンツをディスプレイ114へ表示するためにボタン押下すると、診断結果取得部107がデータ送受信部105を経由してセンタサーバ120から診断結果を取得する。コンテンツ生成部106では、取得した診断結果と、車両情報蓄積部104に格納されている車両101の走行履歴(情報蓄積部104に格納されている車両情報に含まれる位置や時刻情報を基にした車両の走行の軌跡)とに基づいて、ユーザに提供するコンテンツを生成し、ディスプレイ114に表示する。
【0022】
以下に説明する各処理は、車両情報処理サーバであるセンタサーバ120が有するCPUによりプログラムを実行することで実現される。センタサーバ120は、データ送受信部121、走行状態判定部123、優先度決定部125、運転診断部126、利用傾向判定部128、診断結果提供部130、認証部131の各処理を実行する。センタサーバ120は、これらの各処理の実行に用いるデータを格納する、車両情報管理部122、ルール管理部124、診断結果管理部127、提供履歴管理部129、認証情報管理部132を有する。
【0023】
データ送受信部121では、車載端末102と通信する場合には、最初に認証部131で認証処理を行う。認証部131では、車載端末102から送られた車載機IDと、通信に利用された携帯電話番号などの通信装置109を識別する識別情報を用いて認証を行う。認証部131は、車載機IDと携帯電話番号などの識別情報をキーとして認証情報管理部132を検索し、ユーザを特定するユーザIDを取得する。認証成功後、データ送受信部121は、車載端末102からアップロードされた車両情報を、認証部132で特定されたユーザIDと対応付けて車両情報管理部122に蓄積する。
【0024】
なお、認証部131は、車載機IDと携帯電話番号などの識別情報とからユーザを特定するので、特定するユーザは、人としてのドライバではなく、車両101であるとも言える。以下の説明において、分かり易くするために「ユーザ」を用いるが、車両101を示す場合もある。人としてのユーザであるか、車両101としてのユーザであるか、それらのいずれでも良いのかは、文脈から理解されるだろう。
【0025】
運転診断部126では、車両情報管理部122の車両情報を用いて、ユーザの運転がエコドライブであるか否かを診断し、診断結果を診断結果管理部127に格納する。このとき、車両情報管理部122には複数ユーザの車両情報が蓄積されているため、優先度決定部125で決定された優先度に基づいて、優先度の高いユーザから運転診断を行う。運転診断は、エコドライブか否かを診断するエコ運転診断だけでなく、安全運転か否かを診断する安全運転診断でも良い。診断結果提供部130は、車載端末102からの要求に応じて、認証部132で特定したユーザの診断結果を診断結果管理部127から取得して車載端末102へ提供する。診断結果を提供したログを、提供履歴管理部129に記録する。
【0026】
走行状態判定部123では、車両情報管理部122に格納されている車両情報に基づいて、ユーザは、「自宅に接近している」、「目的地まであと1kmである」、「17時12分に走行中である」などの、場所や時間に関する走行状態を判定する。利用傾向判定部128では、提供履歴管理部129に格納されているログを統計処理することで、「最近の診断結果取得回数」、「ユーザが診断結果を取得する可能性の高い場所や時間帯」などの利用傾向を判定する。優先度決定部125では、走行状態判定部123と利用傾向判定部128で判定した走行状態と利用傾向とに基づいて、運転診断部126での運転診断の処理順序を決定するための優先度を決定する。走行状態と利用傾向とは、ユーザからの診断結果の要求状況を表すので、優先度は要求状況の変化に対応したものとなる。すなわち、診断結果の要求の発生が近い将来に推定されるユーザの運転診断ほど、高い優先度が与えられる。
【0027】
図2は、車載端末102のハードウェア構成図を示す。車載端末102は、CPU(プロセッサ)201、RAM202、ROM203、外部記憶装置としてのHDD(ハードディスクドライブ)204、車内ネットワーク110を介してECU111とデータ送受信する車内通信インタフェース205、通信装置107とデータ送受信する外部通信インタフェース206、GPS112、ナビゲーション装置113、ディスプレイ114、入力装置115とデータ送受信する専用通信インタフェース207により構成される。外部記憶装置は、HDDに限らず、光ディスク(DVDなど)装置、フラッシュメモリ装置などを用いても良い。車載端末102は、必要に応じてマニュアル・スイッチにより電源ON/OFFできるようにしてもよいが、車両101のエンジン始動に伴い電源がON(蓄電池に接続)になり、エンジン停止に伴い電源がOFFされ、エンジン作動中は電源ON/OFFのためのマニュアル・スイッチの動作は無効となるように制御されることが望ましい。
【0028】
図1に示した車両情報収集部103、データ送受信部105、コンテンツ生成部106および診断結果取得部107の各プログラムと、車両情報蓄積部104のデータは、HDD204に格納されている。これらのプログラムは、車載端末102の電源ONに伴って、HDD204からRAM202にロードされ、実行される。この場合、ROM203には、プログラム及びプログラムの実行開始時に必要なデータをRAM202にロードするためのローダプログラムが格納される。車両情報蓄積部104にすでに格納されている車両情報は、ローダプログラムによってRAM202にロードされてもよいが、各プログラムの実行に伴い、必要に応じてRAM202にロードされるようにすることにより、RAM202の記憶容量を小さくできる。車両101のエンジン停止に伴い電源がOFFするが、RAM202にあるデータをHDD204に格納する時間は短時間であるので、電源OFFの過渡的な時間でも十分であるが、格納するデータ量が大きい場合などには、電源OFF(車両の蓄電池からの切断)を遅らせればよい。また、エンジン始動状況も含めてデータ収集するような場合には、エンジンの始動準備段階を検知(たとえば、エンジンキーの挿入の検知やユーザの乗車の検知)して電源ON(車両の蓄電池へ接続)し、プログラムの実行を開始すればよい。この場合、ROM203にプログラムを格納しておき、CPU201がROM203のプログラムを実行するようにすれば、プログラムのロードに要する時間が短縮できると共に、その短縮に応じて蓄電池の電力使用量を削減できる。
【0029】
図3は、車両情報蓄積部104のテーブル構成を示す。このテーブル104は、時刻301、車速302、座標303、自宅304、目的地305、アップロード状況306の項目を有する。時刻301は、GPS112から取得する、車両情報を取得した時刻である。車速302は、ECU111から取得する、時刻301で示される時点での車速である。ECU111から取得する情報として車速302を示しているが、センタサーバ120の運転診断部126での診断処理内容に応じた、エンジン回転数、燃料噴射量などの情報も取得する。座標303はGPS112から取得する、時刻301で示される時点で車両101の位置を示す緯度・経度である。自宅304は、ナビゲーション装置113から取得する、「自宅」として予めナビゲーション装置113に登録されている場所の緯度・経度である。目的地305は、ナビゲーション装置113から取得する、時刻301で示される時点で、経路探索のために「目的地」としてナビゲーション装置113に登録されている場所の緯度・経度である。ここでは、自宅304と目的地305を示しているが、「会社」「経由地」など、ナビゲーション装置113に登録されている地点情報も取得するようにしても良い。
【0030】
アップロード状況306は、時刻301〜目的地305の車両情報がセンタサーバ120にアップロードされたか否かを示している。「済」の場合には、時刻301で示される車両情報はアップロード済みであり、「未」の場合には、まだアップロードされていないので、次回以降のセンタサーバ120との通信接続時にアップロードされる。車両情報収集部103が車両情報を蓄積する時に、その車両情報のアップロード状況306は「未」とする。データ送受信部105がセンタサーバ120に車両情報をアップロードした時に、アップロード状況306は「済」に更新される。
【0031】
図4は、センタサーバ120の認証情報管理部132のテーブル構成を示す。このテーブルは、認証のための情報を管理するテーブルであり、ユーザID401、車載機ID402、携帯電話番号403(通信装置109の識別情報)から構成される。ユーザID401はユーザを一意に識別するための識別子であり、車載機IDは車載端末102を一意に識別するための識別子である。認証部131では、車載機ID402と携帯電話番号403からユーザを一意に特定して、ユーザID401を取得する。
【0032】
図5は、センタサーバ120の車両情報管理部122のテーブル構成を示す。このテーブル122は、車載端末102からアップロードされた車両情報を管理するテーブルであり、アップロードされた車両情報に認証部131で特定したユーザIDを付加した構成である。このテーブル122は、ユーザID501、時刻502、車速503、座標504、自宅505、目的地506、診断状況507の項目を有する。時刻502、車速503、座標504、自宅505、目的地506は、図3の車両情報蓄積部104の項目に対応する。ユーザID501は、車両情報である時刻502〜目的地506がどのユーザの情報であるかを示す。
【0033】
診断状況507は、車両情報が運転診断部126で運転診断に用いられたか否かを示している。「済」は運転診断に使用済みを示し、「未」は、まだ運転診断に使用されていないことを示す。車載端末102から車両情報がアップロードされた時点では、診断状況507は「未」として蓄積される。運転診断部126で診断が完了し、結果が診断結果管理部127に蓄積されてから「済」に更新される。時間経過や走行の軌跡を用いる診断項目では、診断状況507が「済」に更新された車両情報が繰返して運転診断に用いられる。
【0034】
図6は、センタサーバ120のルール管理部124のテーブル構成を示す。このテーブル124は、優先度決定部125で優先度スコアを求めるためのルールを管理するテーブルであり、番号601、ルール602、得点603の項目を有する。番号601はルールを識別するための番号で、ルール602はルールの具体的内容、得点603はルールを満たした場合の得点(スコア)を示す。優先度決定部125は、条件を満たしたルール602に対応する得点603を合計した値を優先度スコアとする。図6の例の、番号1のルールで、「自宅」「会社」「目的地」は車載端末102から取得する車両情報である。「リクエスト候補地点」は、提供履歴管理部129のログから統計的に求めるもので、ユーザが診断結果を要求する可能性の高い場所を示す。番号2の「リクエスト候補曜日」、番号3の「リクエスト候補時間帯」も同様で、ユーザが診断結果を要求する可能性の高い曜日と時間帯を示す。
【0035】
図7は、センタサーバ120の診断結果管理部127のテーブル構成を示す。このテーブル127は、運転診断部126で運転診断した結果を格納するテーブルであり、ユーザID701、診断区間702、診断結果703の項目を有する。ユーザID701で示されるユーザの、診断区間702で示される期間の車両情報を使って診断した結果が、診断結果703に格納される。例えば、図の例では、ID=100のユーザは、2009年3月25日10時3分23秒〜11時1分17秒までに、急発進を2回、急加速を3回、アイドリングを35秒行った結果、57ccの燃料を無駄に消費し、無駄がなければ15.3km/Lの燃費で走行できたことを示している。なお、診断区間702は、図7では時間を示しているが、車両101がディスプレイに地図表示に診断結果を重ね合わせて表示する場合には、診断区間702に位置としての区間も含み、診断結果と共に車両101に送信することが望ましい。
【0036】
図8は、センタサーバ120の提供履歴管理部129のテーブル構成を示す。このテーブル129は、ユーザに診断結果を提供した履歴(ログ)を管理しておくテーブルであり、ユーザID801、提供日時802、提供場所803から構成される。提供日時802は、ユーザID801で表されるユーザに診断結果を提供した日時を、提供場所503はユーザに診断結果を提供した場所を示している。提供場所503の位置情報は、車載端末102がセンタサーバ120へ診断結果を要求するときに、その要求に含まれる情報である。例えば、図の例では、ID=100のユーザが、2009年3月29日12時30分40秒に座標(X1,Y1)で、2009年3月30日12時10分32秒に座標(X2,Y2)で診断結果を取得したことを示している。
【0037】
図9は、センタサーバ120での優先度に応じた運転診断処理のフロー図を示す。初めに、運転診断部126は、運転診断に使用していない車両情報を取得するために、車両情報管理部122から診断状況507が「未」の車両情報を検索し、検索結果のユーザID501から、診断対象のユーザの一覧を取得する(ステップ901)。次に、優先度決定部125に問合せて、ステップ901で取得した診断対象ユーザの優先度スコアを決定する。優先度決定部125では、初めに、利用傾向判定部128に問合せて、診断対象ユーザの利用傾向を取得する(ステップ902)。利用傾向判定部128では、提供履歴管理部129から診断対象ユーザの診断結果の提供履歴を検索し、提供履歴を統計処理して、図6のルール602で利用する「リクエスト候補地点」「リクエスト候補曜日」「リクエスト候補時間帯」「リクエスト回数」「リクエスト間隔」を得る。本実施形態では、利用傾向は、提供履歴管理部129を基に求める、車両(ユーザ)が診断結果を要求する、「候補地点」、「候補曜日」及び「候補時間帯」、並びに、提供履歴管理部129に含まれる診断結果を提供した、「回数」及び「間隔」によって表す。これは、ユーザからの要求(リクエスト)に応じて診断結果を提供した履歴から、そのユーザの診断結果の利用傾向を求め、近い将来に診断結果の提供を要求してくる可能性の高さを求めるためである。この可能性の高さを示す指標が、後述する優先度スコアである。
【0038】
リクエスト候補地点を得る方法を示す。まず、提供履歴管理部129から診断対象ユーザへの診断結果の提供履歴を検索し、提供場所803に対応する提供回数を集計する。このとき、提供場所803から一定距離以内にある提供場所は、提供場所803が示す地点と同一地点であると見なす。提供回数の多い地点から順に、一定数の地点をリクエスト候補地点としても良いし、全体の提供回数に対する一定割合の提供回数の地点をリクエスト候補地点としても良いし、提供回数が一定数以上の地点をリクエスト候補地点としても良い。
【0039】
リクエスト候補曜日を得る方法もリクエスト候補地点を得る方法と同様である。診断対象ユーザへの診断結果の提供履歴を提供履歴管理部129から検索し、提供日時を曜日単位で集計し、提供回数の多い曜日から順に、一定数または一定割合の曜日をリクエスト候補曜日としても良いし、提供回数が一定数以上の曜日をリクエスト候補曜日としても良い。また、リクエスト候補時間帯を得る方法も同様であり、診断対象ユーザへの診断結果の提供履歴を検索し、提供日時を時間帯で集計し、提供回数の多い時間帯から順に、一定数または一定割合の時間帯をリクエスト候補時間帯としても良いし、提供回数が一定数以上の時間帯をリクエスト候補時間帯としても良い。ここで、「曜日」は“月曜日”、“火曜日”のようにしても良いし、“平日”と“休日”のようにしても良い。また、「時間帯」は、“17時台”などのように1時間毎にしても良いし、“6〜12時”のように時間間隔を指定しても良いし、午前、午後のようにしても良い。
【0040】
以上例示したように、「候補地点」、「候補曜日」及び「候補時間帯」は、提供履歴の中で、診断結果を提供した回数および比率の少なくとも一方の値が他に比べて高い、場所、曜日及び時間帯である。
【0041】
リクエスト回数は診断対象ユーザへの診断結果の提供回数であり、リクエスト間隔は、診断結果を提供してから、次の診断結果を提供するまでの間隔の平均時間である。
【0042】
「リクエスト候補地点」「リクエスト候補曜日」「リクエスト候補時間帯」「リクエスト回数」「リクエスト間隔」は、対象ユーザの全履歴を対象として算出しても良いし、直近の所定期間、たとえば1ヶ月というように期間を限定して算出しても良い。
【0043】
次に、優先度決定部125は、走行状態判定部123に問合せて診断対象ユーザの走行状態を取得する(ステップ903)。走行状態判定部123では、「特定地点との位置関係」「車両情報の最新時刻」を得る。ここで、特定地点は、車両情報から得た自宅・会社・目的地の何れかの場所、又は、利用傾向判定部128で算出したリクエスト候補地点(場所)を示す。車両101の特定地点との位置関係として、「特定地点に接近中か否か」「特定地点から一定距離以内か否か」を判定する。特定地点に接近中か否か判定を得る方法を示す。まず、車両情報管理部122から、診断対象ユーザの直近の車両情報を取得し、特定地点との距離が徐々に短くなっているか否かで、特定地点に接近中か否かを判定する。直近の車両情報は、時刻502が新しい順に一定数の車両情報としても良いし、最新の10分間というように時間で決定しても良い。また、距離が徐々に短くなるという判定は、特定地点とのユークリッド距離が単調的に短くなるという判定でも良いし、時間と距離のデータにおける回帰直線を求めた場合に距離が短くなっているという判定でも良い。
【0044】
次に、ステップ902とステップ903で取得した利用傾向と走行状態を用いて、ルール管理部124のルールに基づいて優先度スコアを算出する(ステップ904)。例えば、ユーザAの利用傾向が「リクエスト候補曜日=日曜日」「リクエスト候補時間帯=17〜19時台」「リクエスト回数=5回」「リクエスト間隔=3日」で、走行状態が「自宅に接近中である」「自宅から一定距離以内である」「車両情報の最新時刻=2009年3月29日 日曜日 12時20分38秒」であるとする。この時、優先度スコアを計算すると、図6の番号1、番号2、番号5のルールを満たすので、満たしたルールの得点を加算し、3+2+1=6点が優先度スコアとなる。結果として、ルール管理部124のいずれのルールも満足せずに、優先度スコアの合計が0のユーザも発生する。ステップ901で取得した全ユーザの優先度スコアを算出した場合(Yes)にはステップ906に進み、まだ優先度スコアを算出していないユーザがいる場合(No)にはステップ902に戻る(ステップ905)。
【0045】
ステップ901のユーザ一覧を、ステップ904で算出した優先度スコアの降順に並べ替える(ステップ906)。優先度スコアの高いユーザからその車両情報を対象に、ユーザの運転を診断し、診断結果を診断結果管理部127に格納する(ステップ907)。診断を終了した車両情報の診断状況507を「済」に更新する(ステップ908)全ユーザの診断処理が終了した場合(Yes)には処理を終了し、終了していない場合(No)にはステップ907へ戻る(ステップ909)。
【0046】
図10は、ドライバ(ユーザ)へのコンテンツ(運転診断結果)提供のシーケンスを示す。ドライバはコンテンツを要求するためにボタンを押す。車載端末102は、そのボタン押下を入力装置115を介して検知する(ステップ1001)。ドライバからのコンテンツ要求として、ボタン押下ではなく、音声コマンドによる入力を検知するようにしても良い。次に、車載端末102は、センタサーバ120と通信するために、ネットワーク119を介した回線の接続要求を送る(ステップ1002)。この接続要求には、車載端末102を一意に識別するための車載機IDを含む。センタサーバ120では、送られてきた車載機IDと、通信に使用されている携帯電話の番号(通信装置109の識別情報)を用いて、認証部131でドライバ(ユーザ)を認証する(ステップ1011)。このユーザ認証は、車載機IDと携帯電話の番号などの通信装置109の識別情報とによりユーザ(ドライバ又は車両)を特定したと見なす。ユーザを特定できれば通信接続を確立し、特定できなければ通信を切断する(ステップ1012)。
【0047】
通信接続を確立後、診断結果取得部107は、センタサーバ120に対して診断結果の取得要求を送る(ステップ1003)。診断結果の取得要求には、取得したい診断結果の日付、および、車両情報蓄積部104の車両情報に含まれる車両の位置情報を含む。センタサーバ120の診断結果提供部130では、診断結果管理部127から、対象ユーザの指定日付の診断結果を取得して(ステップ1013)、取得した診断結果を応答データとしてデータ送受信部121を介して送信する(ステップ1014)。送信する診断結果は、診断結果管理部127の診断区間702と診断結果703を併せたものである。指定日付の診断結果は一つとは限らず、複数の場合もある。診断結果を受け取った車載端末102は通信を切断する(ステップ1004)。診断結果提供部130は、診断結果を提供したログとして、提供日時や、車載端末102から取得した座標(車両の位置情報)を提供履歴管理部129に蓄積する(ステップ1015)。
【0048】
車載端末102では、コンテンツ生成部106で、受け取った診断結果に基づいて、ディスプレイ114へ表示するコンテンツを生成し(ステップ1005)、生成したコンテンツをディスプレイ114に表示する(ステップ1006)。
【0049】
図11は、コンテンツ生成部106の処理フローを示す。まず、車両情報蓄積部104から、車両101の走行履歴として、診断結果を取得した時刻301の車両情報を取得する(ステップ1101)。次に、診断結果取得部107から診断結果を取得し、診断区間を特定する(ステップ1102)。例えば、図7の上欄の診断結果の場合、診断区間が2009年3月25日10時3分23秒〜11時1分17秒である。次に、地図を含むコンテンツを生成する場合は、走行区間を含む地図情報を取得する(ステップ1103)。ステップ1101で取得した走行履歴から、走行区間の時系列での位置情報(走行経路)を取得、その時系列での位置情報に基づいて、ナビゲーション装置113から地図情報を取得する。最後に、診断結果、走行区間の地図情報などを用いて表示コンテンツを生成する(ステップ1104)。
【0050】
図12A及び図12Bは、ドライバへ提供する、ディスプレイ114の画面例を示す。図12Aは、メニュー画面であり、ドライバは「今日のエコドライブ結果」ボタンを押すことで、その日の運転診断結果を見る。図12Bは、3月25日の運転診断結果を表示した画面例である。「エコドライブ度」は、診断日がエコ運転であったか否かを点数化したものであり、センタサーバ120の運転診断部126で計算されたものである。「過剰消費量」は、発進や急加速などの非エコ運転によって無駄に消費された燃料量を、「推定燃費」は過剰消費量が0だった場合の燃費を示しており、どちらも運転診断部126で算出されたものである。図示を省略するが、走行経路を含む地図を必要に応じてディスプレイ114に表示する。
【0051】
以上のように本実施形態によれば、ユーザからの診断結果の要求の発生を推定し、その要求に対応する車両情報を対象に優先的に運転診断できる。
【符号の説明】
【0052】
101:車両、102:車載端末、103:車両情報収集部、104:車両情報蓄積部、105:データ送受信部、106:コンテンツ生成部、107:診断結果取得部、109:通信装置、110:車内ネットワーク、111:ECU、112:GPS、113:ナビゲーション装置、114:ディスプレイ、115:入力装置、119:ネットワーク、120:センタサーバ、121:データ送受信部、122:車両情報管理部、123:走行状態判定部、124:ルール管理部、125:優先度決定部、126:運転診断部、127:診断結果管理部、128:利用傾向判定部、129:提供履歴管理部、130:診断結果提供部、131:認証部、132:認証情報管理部。

【特許請求の範囲】
【請求項1】
車両の運転診断を実行する車両情報処理システムにおける車両情報処理方法であって、
前記車両から車両情報を収集し、
前記車両への前記運転診断の診断結果の提供履歴から前記診断結果の利用傾向を求め、
収集した前記車両情報から前記車両の走行状態を求め、
求めた前記利用傾向と前記走行状態とに応じた優先度に基づいて、収集した前記車両情報を用いて前記車両の運転診断を実行することを特徴とする車両情報処理方法。
【請求項2】
前記利用傾向は、前記車両が前記診断結果を要求する、「候補地点」、「候補曜日」及び「候補時間帯」、並びに、前記提供履歴に含まれる前記診断結果を提供した、「回数」及び「間隔」で表すことを特徴とする請求項1記載の車両情報処理方法。
【請求項3】
前記「候補地点」、前記「候補曜日」及び前記「候補時間帯」は、前記提供履歴の中で、前記診断結果を提供した回数および比率の少なくとも一方の値が他に比べて高い、場所、曜日及び時間帯であることを特徴とする請求項2記載の車両情報処理方法。
【請求項4】
前記利用傾向は、少なくとも直近の所定期間分を含む前記提供履歴から求めることを特徴とする請求項2記載の車両情報処理方法。
【請求項5】
前記走行状態は、前記車両の位置と特定地点との位置関係として、「前記車両が特定地点へ接近中か否か」及び「前記車両が特定地点の近辺を走行中か否か」を表すことを特徴とする請求項1記載の車両情報処理方法。
【請求項6】
前記特定地点は、前記車両へ搭載された機器に登録され、前記車両情報に含まれる場所、及び、前記提供履歴の中で、前記診断結果を提供した回数および比率の少なくとも一方の値が他に比べて高い場所の何れかであることを特徴とする請求項5記載の車両情報処理方法。
【請求項7】
車両から車両情報を受信し、前記車両の運転診断の診断結果を送信するデータ送受信部、前記データ送受信部により、前記診断結果を前記車両へ送信した提供履歴を格納する提供履歴管理部、
前記提供履歴管理部に格納される前記診断結果の提供履歴から利用傾向を求める利用傾向判定部、
受信した前記車両情報から前記車両の走行状態を求める走行状態判定部、
求めた前記利用傾向と前記走行状態とに応じた優先度に基づいて、前記車両情報を用いて前記車両を運転診断する運転診断部、及び
前記運転診断部による運転診断の診断結果を、前記データ送受信部を用いて送信する診断結果提供部を有することを特徴とする車両情報処理サーバ。
【請求項8】
前記利用傾向判定部が求める前記利用傾向は、前記車両が前記診断結果を要求する、「候補地点」、「候補曜日」及び「候補時間帯」、並びに、前記提供履歴に含まれる前記診断結果を提供した、「回数」及び「間隔」であることを特徴とする請求項7記載の車両情報処理サーバ。
【請求項9】
前記「候補地点」、前記「候補曜日」及び前記「候補時間帯」は、前記提供履歴の中で、前記診断結果を提供した回数および比率の少なくとも一方の値が他に比べて高い、場所、曜日及び時間帯であることを特徴とする請求項8記載の車両情報処理サーバ。
【請求項10】
前記利用傾向判定部は、前記提供履歴管理部に格納される、少なくとも直近の所定期間分を含む前記提供履歴から求めることを特徴とする請求項8記載の車両情報処理サーバ。
【請求項11】
前記走行状態判定部が求める前記走行状態は、前記車両の位置と特定地点との位置関係として、「前記車両が特定地点へ接近中か否か」及び「前記車両が特定地点の近辺を走行中か否か」であることを特徴とする請求項7記載の車両情報処理サーバ。
【請求項12】
前記特定地点は、前記車両へ搭載された機器に登録され、前記データ送受信部が受信する前記車両情報に含まれる場所、及び、前記提供履歴の中で、前記診断結果を提供した回数および比率の少なくとも一方の値が他に比べて高い場所の何れかであることを特徴とする請求項11記載の車両情報処理サーバ。
【請求項13】
前記診断結果提供部は、前記診断結果の送信に対応して、前記診断結果を提供したログを、前記提供履歴管理部に格納される前記診断結果の提供履歴として追加することを特徴とする請求項7記載の車両情報処理サーバ。

【図1】
image rotate

【図2】
image rotate

【図3】
image rotate

【図4】
image rotate

【図5】
image rotate

【図6】
image rotate

【図7】
image rotate

【図8】
image rotate

【図9】
image rotate

【図10】
image rotate

【図11】
image rotate

【図12A】
image rotate

【図12B】
image rotate


【公開番号】特開2011−12968(P2011−12968A)
【公開日】平成23年1月20日(2011.1.20)
【国際特許分類】
【出願番号】特願2009−154638(P2009−154638)
【出願日】平成21年6月30日(2009.6.30)
【出願人】(509186579)日立オートモティブシステムズ株式会社 (2,205)
【Fターム(参考)】