JP5121416B2 - 車両情報管理装置、方法およびプログラム - Google Patents

Description

本発明は、車両情報を管理する方法及びその装置に係わる。

地球温暖化防止のため、自動車の二酸化炭素排出量削減が求められている。二酸化炭素排出量、すなわち、燃料消費量の削減を目的として、ドライバ一人ひとりが、アイドリングストップをはじめとするエコドライブ（環境に配慮した自動車の使い方）を実践することが推奨されている。そして、効果的なエコドライブを実践してもらうためには、車両情報を収集して燃費や運転方法を診断し、実際にどのように運転しているのかをドライバに認知させ、その上で、どのように改善したら良いのかをアドバイスする必要がある。しかし、車載ハードディスクなどの記憶装置の記憶容量は有限であるため、車両情報の全て蓄積することはできない。記憶容量の大きいハードディスクを用意するにはコストがかかるし、そもそも、ドライバによって車両の利用頻度、走行時間、走行距離などが異なるため、どのぐらいの記憶容量が必要なのかを推定することが困難である。そのため、限られた記憶容量の中で、効率的にデータ（車両情報）を管理する必要がある。

データ管理を行うための従来技術として、一定時間毎に車両情報を蓄積すると、車速に応じてデータの精度にバラツキが発生するため、車速に応じて車両情報を蓄積するサンプリングを変える方法がある。例えば、特許文献１（特開平７−２９６２１０）に開示されているように、車両用データを記録するためのサンプリング信号の間隔を、車両の走行速度に応じて変化させることにより、車両が高速走行しているときに低速走行時よりサンプリング信号の出力間隔を短くすることができ、車両の周囲の状況の変化に応じたデータを記録することができる。

また、別のデータ管理を行うための従来技術として、一定時間や一定距離毎に、車両情報を統計処理することで圧縮する方法がある。例えば、特許文献２（特開２００６−５３９８７）に開示されているように、故障解析などのために詳細な車両の状態情報が必要となる最近の期間については、各時点における車両の状態を表すログ情報をそのまま記録装置に保持しつつ、それ以前の期間については、ログ情報をそのまま保持するのではなく、車両の状態の統計値を表す統計情報のみを記録装置に保持することにより記録装置の記憶容量の消費を抑制する。統計情報として、走行距離に対する平均燃費、道路区間毎の通過回数が例示されている。

特開平７−２９６２１０ 特開２００６−５３９８７

車速に応じて車両情報を記録するサンプリング周期を変える上記特許文献１の方法は、車両情報の連続記録よりも記録装置の容量が少ないことを前提としているが、走行速度によって記録する車両情報の精度が異なることを課題にしたものである。これは、高速走行時における緊急状況の再現のための車両情報の精度が低速走行時に比べて悪いことを考慮している。

上記特許文献２のような、一定時間や一定距離毎に、車両情報を統計処理する方法は、走行距離に対する平均燃費、道路区間毎の通過回数の例示から分かるように、所定の記憶容量に可能な限り長時間又は長距離にわたる車両情報を記録することを考慮したものである。

このように、特許文献１及び特許文献２は、車両情報を記録するという視点で、その精度や記憶容量に着目しているが、記録した車両情報をどのように見るかというユーザの視点が考慮されていない。

ユーザは、たとえば、走行した区間、運転状態、道路や天候の状況などと燃費やタイヤの磨耗などとの関係を知りたいために、車両情報の記録(管理)装置を使用する。すなわち、ユーザの知りたい観点の情報（種々の情報間の関係を含む）とその精度が車両情報の記録(管理)装置に求められる。逆に言えば、ユーザに求められる車両情報が、他の車両情報との関連を含めて、必要とされる精度で記録されれば、車両情報の記録(管理)装置の使命を達成することができるので、必要以上の情報や必要以上の精度による記録を排除することにより、車両情報の記録(管理)装置の記憶容量を適正に使用できることになる。

車両情報の一つである燃費(燃料消費量／走行距離)に関して具体的に言えば、一般道、高速、渋滞など、走行状態によって平均燃費は大きく異なる。走行状態を区別することなく一定距離で燃費のデータを蓄積してしまうと、そもそも燃費の異なる区間を統合してしまうこととなり、後でユーザが見た場合に、運転方法が悪くて燃費が悪くなったのか、渋滞でしょうがなく燃費が悪くなったのかなどを区別することができない。また、一定距離で残す方法では、距離の長い、しかも燃費の変化が少ない高速のデータをより多く残すこととなり、容量の限られた車載ハードディスクの効率的な利用ができない。

また、一定時間や一定距離毎に、車両情報を統計処理すると、後でユーザが見た場合に、燃費が変動した原因が分からなくなる。実際は途中の渋滞のために燃費が悪くなったのに、その前後の区間とまとめて統計処理すると、ユーザはなぜ燃費が悪くなったのかを知ることができない。

このように必要以上の情報や必要以上の精度による記録を排除することがデータの圧縮になる。したがって、車両情報記録(管理)装置においては、ユーザが求める(着目する)情報及びその精度を満足する範囲で、その情報に関連して収集したデータ(車両情報)を間引いたり、統計処理したり、その他のデータ圧縮技術を用いたりして、データ圧縮することが求められる。

本発明に係る車両情報管理装置及びその方法は、車両の走行状態と関連する車両情報(たとえば、燃費)を含む、車両搭載機器からの車両情報を取得し、取得した車両情報から走行状態を判定して、判定した走行状態に基づいて取得した車両情報の圧縮方法を決定し、決定した圧縮方法で、走行状態の区間の走行状態と関連する車両情報を含む車両情報を圧縮して、圧縮した車両情報を判定した走行状態の区間に対応させて記録する車両情報管理装置及びその方法として構成される。

本発明の他の態様によれば、判定した走行状態に対応して、距離、時間及び区間の少なくとも一つの尺度に基づいた圧縮方法を選択する。

本発明によれば、走行状態に応じて車両情報の圧縮方法を変更することで、ユーザに求められる車両情報が、他の車両情報との関連を含めて、必要とされる精度で記録され、必要以上の情報や必要以上の精度による記録を排除することにより、車両情報の記録(管理)装置の記憶容量を適正に使用できる。

以下に、本発明の実施形態について、図を用いて詳細に説明する。

図１は、本実施例のシステム構成図を示す。本システムは、車両１０１とセンタサーバ１２０から構成される。車両１０１とセンタサーバ１２０はネットワーク１１９で接続されている。ネットワーク１１９は、携帯電話網でも良いし、無線ＬＡＮでも良いし、ＤＳＲＣ（Dedicated Short Range Communication：専用狭域通信）でも良い。センタサーバ１２０では、車両１０１から送られた車両情報をグラフ化などしてユーザに提供する。

なお、本実施例では、ネットワーク119を介して接続するセンタサーバ１２０として説明するが、小型化されたサーバを車両に搭載して、システムを構成しても良い。

車両１０１には、通信装置１１７、ナビゲーション端末１１８、車両情報記録装置１０２、ＧＰＳ１１４、ＥＣＵ１１５、及び車内ネットワーク１１６が搭載される。ECU１１５はElectric Control Unit（電子制御装置）で、車のエンジンや足回りなどの制御を行うものである。車両情報記録装置１０２とECU１０５は、車内ネットワーク１１６で接続されており、車両情報記録装置１０２は、車内ネットワーク１１６を介して、エンジン回転数やアクセル開度といったECU１１５が持っている情報を取得する。本実施例は車両情報の取得先としてECU１１５また車両情報記録装置１０２は、ＧＰＳ１１４やナビゲーション端末１１８と接続して、ＧＰＳ情報やナビゲーション端末が持っている地図情報を取得する。本実施例では車両情報の取得先としてECU１１５、ＧＰＳ１１４及びナビゲーション端末１１８を説明するが、必要に応じてブレーキ装置などの搭載機器、各種センサ、各種計器も、車内ネットワークを介して、又は直接接続して車両情報の取得先とする。通信装置１１７は、ネットワーク１１９を介してセンタサーバ１２０に車両情報を送信する。

本実施例では、車両情報を車両の走行に関わる情報として説明するが、走行に直接的には関わらない搭載機器や部品の状況、たとえば窓の開閉回数などもユーザの必要性に応じて車両情報として扱ってもよい。

以下に説明する各処理は、車両情報記録装置１１２が有するＣＰＵによりプログラムを実行することで実現される。車両情報記録装置１０２は、データ収集部１０３、データ送信部１０４、データ圧縮部１０５、及び走行状態判定部１０６の各処理を実行する。車両情報記録装置１０２は、これらの各処理の実行に用いるデータ(テーブル)を格納する走行目的推定部１０７、車両情報管理部１０８、圧縮ルール管理部１０９、渋滞定義管理部１１０、地図情報管理部１１１、推定ルール管理部１１２、及び圧縮情報管理部１１３を有する。

データ収集部１０３は、車内ネットワーク１１６を介してECU１１５から車速などの車両情報を取得する。またＧＰＳ１１４からＧＰＳ情報(位置情報)を取得する。取得した情報は車両情報管理部１０８に蓄積する。

データ圧縮部１０５は、車両情報管理部１０８から蓄積されている車両情報を走行状態判定部１０６と走行目的推定部１０７を渡して走行状態と走行目的を求める。求めた走行状態・走行目的と、圧縮ルール管理部１０９に格納されている圧縮ルールから、圧縮率や圧縮方法を決定し、決定した方法で車両情報を圧縮して圧縮情報管理部１１３に記録する。

走行状態判定部１０６は、地図情報管理部１１１の地図情報に基づいて道路種別を判定する。また、渋滞定義管理部１１０の渋滞定義に基づいて渋滞を判定する。さらに、これらの判定結果を用いて車両の走行状態を判定する。

走行目的推定部１０７は、地図情報管理部１１１の自宅情報、目的地情報、経路情報、さらに推定ルール管理部１１２の推定ルールに基づいて車両の走行目的を推定する。データ送信部１０４は、圧縮情報管理部１１３から圧縮情報を取得し、通信装置１１７を介してセンタサーバ１２０に情報を送る。

図２は車両情報記録装置１０２のハードウェア構成図を示す。車両情報記録装置１０２は、CPU(プロセッサ)201、RAM202、ROM203、ＧＰＳ情報を取得するためのセンサであるＧＰＳ装置(以下、GPS)２０４、外部記憶装置としてのＨＤＤ(ハードディスクドライブ)２０５、車内ネットワーク１１６を介してECU１１５などとデータ送受信する車内通信インターフェイス206、及びネットワーク１１９を介してセンタサーバ120とデータ送受信する外部通信インターフェイス207により構成される。また、GPS114やナビゲーション端末１１８と車内通信インターフェイス206を介して接続できない場合は、それぞれに専用の通信インターフェースを持つ。

外部記憶装置は、ＨＤＤに限らず、光ディスク（DVDなど）装置、フラッシュメモリ装置などを用いても良い。

車両情報記録装置１０２は、車両のエンジンが停止中は必要に応じてマニュアル・スイッチにより電源ON/OFFできるようにしてもよいが、車両のエンジン始動に伴い電源がON(蓄電池に接続)になり、エンジン停止に伴い電源がOFFされ、エンジンが作動中は電源ON/OFFのためのマニュアル・スイッチの動作は無効となるように制御されることが望ましい。

図１に示したデータ収集部１０３、データ送信部１０４、データ圧縮部１０５、走行状態判定部１０６、及び走行目的推定部１０７の各プログラムと、車両情報管理部１０８、圧縮ルール管理部１０９、渋滞定義管理部１１０、地図情報管理部１１１、推定ルール管理部１１２、及び圧縮情報管理部１１３のデータ(テーブル)は、ＨＤＤ２０５に格納されている。これらのプログラム及びデータ(テーブル)は、車両情報記録装置１０２の電源ONに伴って、ＨＤＤ２０５からＲＡＭ２０２に、ロードされ、各プログラムは実行を開始する。この場合、ROM２０３にはプログラム及びデータ(テーブル)をＲＡＭ２０２にロードするためのローダプログラムが格納される。

車両のエンジン始動から走行開始までの、通常のドライバーの動作時間に比べれば、プログラムやデータのロード時間は十分短いので、上記の構成が望ましい。また、エンジン停止に伴い電源がOFFするが、RAM202にあるデータ(テーブル)の内容をＨＤＤ２０５に格納する時間も短時間であり、電源OFFの過渡的な時間でも十分であるが、格納するデータ容量が大きい場合などには、電源OFF（車両の蓄電池からの切断）を遅らせればよい。

なお、エンジン始動状況も含めてデータ収集するような場合は、エンジンの始動準備段階を検知(たとえば、エンジンキーの挿入を検知)して、電源ONし、プログラムの実行を開始すればよい。このような場合、ＨＤＤ２０５からＲＡＭ２０２へのプログラムロード時間が問題になるならば、プログラムをROM２０３へ格納しておき、実行開始する。

図３は、車両情報管理部１０８のテーブル構成を示す。このテーブルは、日時３０１、走行距離３０２、座標３０３、燃料噴射量３０４、及び車速３０５から構成される。このテーブル構成は、燃費と走行状態との関係を記録するための例であり、着目する車両情報が燃費以外であれば、その情報に対応して関連する項目が選択される。

日時３０１は車両情報を取得した日時である。図２の説明では、図示も含めて省略したが、車両情報記録装置１０２は、年月日、日付、及び時刻データを得るための時計や、時間間隔を計るためのタイマを備えている。日時３０１は、そのような時計から得たデータである。走行距離３０２は、ＥＣＵ１１５から取得する情報であり、日時３０１で示される時点での走行距離である。座標３０３は、ＧＰＳ１１４から取得する情報であり、日時３０１で示される時点での車両位置の経度(x座標)及び緯度（ｙ座標）である。燃料噴射量３０４は、ＥＣＵ１１５から取得する情報であり、日時３０１で示される時点での燃料噴射量である。車速３０５は、ＥＣＵ１１５から取得する情報であり、日時３０１で示される時点での車速(車両の走行速度)である。

図４は、圧縮ルール管理部１０９のテーブル構成を示す。図４(A)は、圧縮ルール設定値テーブルであり、このテーブルに設定されている値に基づいてデータ圧縮部１０５で車両情報が圧縮される。圧縮ルール設定値テーブルは、走行状態４０１、尺度４０２、圧縮率４０３から構成される。走行状態４０１は、「平地」「山道」「高速」「渋滞」といった走行状態であり、走行状態毎に尺度４０２と圧縮率４０３が設定される。また、走行状態４０１の値は、走行状態判定部１０６で判定される値と同じである。本実施例では、走行状態判定部１０６では、走行状態として「平地」「山道」「高速」「渋滞」の４つの何れかに判定される。「平地」「山道」及び「高速」は、車両の制限速度に対応した走行状態と考えても良い。なお、これらの走行状態の呼称は、ユーザに理解され易い一般的な用語(日常語)による呼称が望ましい。

本実施例では走行状態の定義が４つであるが、５つ以上でも３つ以下でも良い。また、本実施例の定義は「平地」「山道」「高速」「渋滞」であるが、高速を高速(郊外)と都市高速（市街地）とその他の有料道路などに分けても良いし、渋滞を一般道渋滞と高速道渋滞に分けても良いし、国道と県道などの区別を入れても良いし、都市部と郊外を分けても良い。また、天候（晴天、雨天など）との組み合わせにより、走行状態を細分化しても良い。さらに路面状況（舗装、砂利、積雪など）や道路状況（勾配や直線／曲線など）との組み合わせにより走行状態を細分化しても良い。

走行状態の定義は、ユーザが望む情報との関係で決めることが望ましい。ユーザが望む情報が燃費に関わる情報であれば、たとえば本実施例のような4つの定義でよい。ユーザが望む情報がタイヤの磨耗に関わる情報であれば、たとえば、本実施例のような4つの定義に天候、路面状況、道路状況などを組み合わせた細分化した定義にする。

走行状態を細分化した場合の呼称は、上記のように組み合わせにより細分化されることが多く、呼称も日常語の組み合わせとして、たとえば「雨天の高速」のようにすることがユーザにとって望ましい。

尺度４０２は、車両情報を圧縮するための軸を表しており、「距離」「時間」「区間」の何れかが設定される。尺度４０２は、走行状態の定義に応じて選択される。圧縮率(圧縮レベル)４０３は、図４(B)の圧縮ルール定義テーブルで定義されるレベルの中から、ドライバが一つを選択して設定する。ここで、設定はカーメーカやディーラが決めてもよいし、同車種の車は同じ設定にしても良い。

図４(B)は圧縮ルール定義テーブルで、各走行状態で設定可能な圧縮率を表している。圧縮ルール定義テーブルは、走行状態４０４、尺度４０５、圧縮率(圧縮レベル)４０６から構成される。走行状態４０４は走行状態を表しており、図4(A)の圧縮設定値テーブルの走行状態４０１に対応している。尺度４０５と圧縮率４０６は、設定可能な圧縮の定義を表しており、「距離」「時間」「区間」の各尺度で、レベル１からレベル３までが設定可能であることを示している。

例えば、走行状態が「平地」、尺度が「距離」、圧縮率が「レベル２」の設定した場合、走行状態が平地の場合の車両情報は、５０ｋｍ単位で情報を圧縮することを表している。また、例えば、走行状態が「渋滞」、尺度が「時間」、圧縮率が「レベル２」の設定した場合、走行状態が渋滞の場合の車両情報は、１時間単位で情報を圧縮することを表している。また、例えば、走行状態が「高速」、尺度が「区間」、圧縮率が「レベル３」の設定をした場合には、走行状態が高速の場合の車両情報は、１区間単位で情報を圧縮することを表している。

図４(B)の例では、１０ｋｍや１００ｋｍでの平均値を残すレベルしか示していないが、情報を全く残さないレベルを設定しても良い。そうすることで、平地の情報は残さずに、高速の情報のみを圧縮して残すことが可能となる。一般的に、高速道路では平均車速は早いし、渋滞では平均車速は遅い。同じ距離で平均化して車両情報を蓄積すると、平均車速の早い高速道路の情報を多く蓄積することとなり、結果として、蓄積した情報の大部分が高速道路の情報になってしまう可能性がある。そのため、尺度が距離の場合には、同じレベルでも走行状態によって圧縮率を変更するようにする。つまり、平均化する距離を変更する。例えば、渋滞の「距離」「レベル１」では３ｋｍ平均なのに対して、より平均車速の早い高速道路の場合は５００ｋｍ平均とする。こうすることで、蓄積される情報の偏りを防ぐことができる。走行状態間でどれぐらいの比率にしたら良いかは、統計データから平均車速を求めて決めても良いし、道路の制限速度の比率から決めても良い。

図４(C)は区間定義テーブルで、尺度４０５で用いる「区間」の定義を表している。区間定義テーブルは、走行状態４０７、区間定義４０８から構成され、各走行状態での区間が定義されている。例えば、「高速」での区間は、インターチェンジ、サービスエリア、パーキングエリア、料金所、分岐点といった物理的なランドマークで区切られる区間を指す。

図４(A)では、高速は１区間単位で圧縮する設定であるので、例えば、車両情報はサービスエリアからサービスエリアまでの平均燃費や走行距離として計算されて圧縮されることとなる。走行状態が平地や山道の場合には交差点から交差点までが１区間であり、渋滞の場合には渋滞にはまっている区間が１区間となる。区間の定義としては、細かい区間に区切るのではなく、道路種別が同じ区間全体を1区間と定義しても良い。例えば、平地から高速へと走行した場合、平地の全走行を1区間、高速の全走行を1区間となるように定義する。また、車両状態を用いて区間を定義しても良い。例えば、エンジン始動から走行を経てエンジン停止を1区間と定義しても良いし、アイドリングから走行を経てアイドングを1区間と定義しても良い。また、これらの組み合わせで定義しても良い。

図４に示した、圧縮ルール管理部１０９のテーブルは、燃費と走行状態との関係を記録するための例示であり、着目する車両情報が燃費以外であれば、その情報に対応して関連する項目やその内容が選択される。たとえば、タイヤの磨耗に着目する場合は、走行状態を道路状況や路面状況などにより細分化し、タイヤの磨耗を早める要因になる車輪の滑走や空転が生じ易い走行状態の区間では低い圧縮率を用い、他の走行状態の区間では高い圧縮率を用いる。

図５は、渋滞定義管理部１１０のテーブル構成を示す。これは、渋滞を平均車速で定義したもので、走行状態判定部１０６では、平均車速が設定された値を下回った場合には渋滞と判断する。このテーブルは、道路種別５０１と平均車速５０２から構成される。渋滞になった場合の平均車速は、道路種別によって差があるため、道路種別毎に平均車速が定義されている。今回の例では、平地や山道では２０ｋｍ/時、高速では４０ｋｍ/時となっている。今回は道路種別のみで分類しているが、天候や場所などによって詳細に分類しても良い。

また、渋滞情報などを提供する道路情報システムから渋滞情報が得られるならば、得られた情報に従って渋滞を認識しても良い。

図６は、推定ルール管理部１１２のテーブル構成を示す。図６(A)は走行目的定義テーブルで、走行状態を推定するためのルールが定義されている。走行目的定義テーブルは、走行目的６０１と推定方法６０２から構成される。車両情報が推定方法６０２の条件を満たした場合に、対応する走行目的６０１と判断される。例えば、自宅から１００ｋｍ以上離れた場合には、走行目的を旅行と推定する。また、例えば、平日で、事前定義された自宅〜会社間の経路から５ｋｍ以内の範囲で走行していれば通勤と推定する。走行目的推定部１０７では、一日分の車両情報に対して本ルールが適用され、上から順に判定して行き、最初に条件を満たしたものを走行目的とする。

図６(B)は、圧縮率補正定義テーブルであり、走行目的によって圧縮率をどう補正するかを定義している。圧縮率補正定義テーブルは、走行目的６０３と補正方法６０４から構成される。走行目的６０３は図６(A)の走行目的６０１と対応している。補正方法６０４は、走行目的に対する圧縮率の補正方法が表されている。例えば、走行目的が旅行の場合には圧縮率のレベルを１つ上げて補正し、走行目的が通勤の場合にはレベルを補正しない。

ここでレベルを上げるとは、レベル１からレベル２に、レベル２からレベル３にすることである。ここで、レベルを上げるということは、より詳細に車両情報を蓄積することを意味している。例えば、平地の場合、レベル１では１００ｋｍ平均の情報を蓄積するのに対して、レベル２では５０ｋｍ平均の情報を蓄積するので、レベル２はレベル１の２倍の情報を蓄積することとなる。ユーザが閲覧したい車両情報にはバラツキがある。全ての情報を平均的に見たいのではなく、より詳しく見たい情報とそうでない情報がある。例えば、旅行などのイベント時の車両情報は詳しく見たいが、普通の週末に車両に乗っているときの車両情報はそんなに詳しくなくても良い、という場合がある。また別の場合では、平日の通勤時の車両情報は詳しく見たいが、週末の車両情報をそんなに詳しくなくても良い、という場合もある。ユーザは、車両情報を詳しく見たい又は詳しくなくても良いと漠然と判断するのではなく、たとえば燃費との関係の下で判断する。このように、ユーザが閲覧したい情報を詳細に残すために、走行目的に応じて圧縮率を変更できるようにする。

図７は、圧縮情報管理部１１３のテーブル構成を示す。これは、図３で示した車両情報を圧縮した情報を格納するテーブルであり、図３の複数レコードが１レコードに圧縮されて格納される。このテーブルは、日時７０１、走行距離７０２、座標７０３、燃料噴射量７０４、車速７０５、及び走行状態７０６から構成される。日時７０１、走行距離７０２、座標７０３、燃料噴射量７０４、及び車速７０５は図３と対応するカラムであり、走行状態７０６は走行状態判定部１０６で判定された値である。各項目の計算方法の詳細に関しては、図８を参照して後述する。

図８は、データ圧縮部１０５における車両情報圧縮処理のフローを示す。まず、圧縮ルール管理部１０９から、圧縮ルール設定値テーブル（図４(A)）、圧縮ルール定義テーブル（図４(B)）、区間定義テーブル（図４(C)）を読み込む（ステップ８０１）。車両情報管理部１０８から一日分の車両情報を読み込む。車両情報管理部１０８には複数日の車両情報が格納されているので、それを古い順に処理しても良いし、新しい順に処理しても良い。例えば、処理している日が2007年8月8日の場合には、2007年8月7日の車両情報を読み込む（ステップ８０２）。走行目的推定部１０７で、一日分の車両情報から走行目的を推定して圧縮率を補正する（ステップ８０３）。詳しくは、図９を参照して後述する。

走行状態判定部１０６で、一日分の車両情報から走行状態を判定し、判定した結果に基づいて、連続した走行状態毎にデータを分割する（ステップ８０４）。分割データは複数の車両情報（図３での複数レコード）から構成される。詳しくは、図１０を参照して後述する。

車両情報を圧縮し（ステップ８０５）、圧縮情報管理部１１３に格納する（ステップ８０６）。ステップ８０５では、まず、データを圧縮する単位として、ステップ８０４で分割された分割データの一つを選択する。そして、ステップ８０２で求めた圧縮率の補正と、ステップ８０３で求めた走行状態から、車両情報を圧縮するための尺度と圧縮率を求める（圧縮ルールから選択する）。例えば、ステップ８０２で、走行目的が「旅行」で補正方法が「レベルを一つ上げる」であるとする。ステップ８０３で、走行状態が「平地」であるとすると、図４(A)より尺度が「距離」で圧縮率が「レベル２」となる。走行目的による補正が「レベルを一つ上げる」なので、最終的には尺度が「距離」、圧縮率が「レベル３」となる。走行状態が「平地」、尺度が「距離」、圧縮率が「レベル３」の場合、図４(B)を参照すると走行距離１０ｋｍ単位で車両情報を圧縮することとなる。圧縮の仕方は項目毎によって異なり、「日時」「走行距離」「座標」は、複数の車両情報（１０ｋｍ分）の最初と最後だけを残す。「燃料噴射量」は複数の車両情報（１０ｋｍ分）の合計値にし、「車速」は複数の車両情報（１０ｋｍ分）の平均値にする。図７の日時７０１、走行距離７０２、座標７０３には最初と最後の日時と走行距離と座標が格納されている。例えば、”2007/7/5 10:47:41”が最初の日時で、”2007/7/5 10:59:18”が最後の日時である。燃料噴射量７０４には、１０ｋｍ分の燃料噴射量の合計値が格納されており、車速７０５には１０ｋｍ分の車速の平均値が格納されている。また、走行状態７０６には、ステップ８０４で判定された走行状態が格納されている。

ここで、走行状態が「高速」の場合には、データ量を少しでも減らすため、走行距離７０２には最初の値だけしか格納しないこととする。高速道路の場合、入口と出口さえ分かれば、地図情報から、入口から出口までの距離を算出することができる。そのため、座標７０３から入口と出口は特定できるので、走行距離７０６には最後の値を省略しても後から補完することが可能となる。

ステップ８０４で分割した分割データを全て圧縮した場合（Ｙｅｓ）にはステップ８０８に、そうでない場合（Ｎｏ）にはステップ８０５に進む（ステップ８０７）。ステップ８０７までで一日分の車両情報の処理が完了するので、まだ処理していない日にちの車両情報がある場合（Ｎｏ）にはステップ８０２に戻り、全て終了している場合（Ｙｅｓ）には車両情報圧縮処理を終了する（ステップ８０８）。この車両情報圧縮処理は、タイマを使って定期的（たとえば、6時間、2日、又は1週間毎に）に実行するようにしても良いし、所定量の車両情報が蓄積されたことをトリガとして実行しても良いし、エンジン始動をトリガとして実行しても良い。

図９は、走行目的推定部１０７のフローを示す。まず、推定ルール管理部１１２から、走行目的定義テーブル（図６(A)）、圧縮率補正定義テーブル（図６(B)）を読み込む（ステップ９０１）。次に、地図情報管理部１１１から、処理に必要となるナビ情報(ナビゲーション情報)を読み込む（ステップ９０２）。ここの例では、処理に必要となるナビ情報は、走行目的の「旅行」を判断するための”自宅の位置”、走行目的の「通勤」を判断するための”自宅〜会社間の経路”である。地図情報管理部１１１はナビゲーション端末１１８と接続しており、ナビゲーション端末１１８が持っている自宅の位置、会社の位置、自宅〜会社間の経路などの情報を取得することができる。

データ圧縮部１０５から渡された、一日分の車両情報から走行目的を推定する（ステップ９０３）。車両情報が、ステップ９０１で読み込んだ走行目的定義テーブル（図６(A)）の推定方法602に合うかどうかを、上から順に確認していく。例えば、まずは「旅行」を判定するために、自宅から最も離れた時の距離を車両情報から計算する。その距離が１００ｋｍを超えていれば、走行目的601が「旅行」であると判定し、超えていなければ「通勤」の判定に移る。走行目的601が「通勤」の判定では、日時から曜日を求め、曜日が月〜金曜かどうかを確認する。月〜金曜の場合には、一日の全ての車両情報が、自宅〜会社間の経路から５ｋｍ以内かどうかを調べることで「通勤」を判定する。

走行目的定義テーブル（図６(A)）の全ての走行目的に合わなかった場合には、走行目的が判定できなかったこととなる。走行目的が判定(推定)できた場合（Ｙｅｓ）にはステップ９０５に進み、判定(推定)できなかった場合（Ｎｏ）には終了する（ステップ９０４）。走行目的が推定できた場合には、ステップ９０１で読み込んだ圧縮率補正定義テーブル（図６(B)）に基づいて、すなわち、推定した走行目的603に対応した補正方法604に基づいて、圧縮率を補正する（ステップ９０５）。今回の例では、車両情報から「旅行」や「通勤」を推定しているが、ドライバが運転する時に、ボタンを押すなどの操作で「旅行」や「通勤」を直接指定するようにしても良い。また、デフォルトとして、個々のドライバにとって最も多い（長時間又は高頻度）の走行目的(たとえば、「通勤」)を指定するようにして、他の走行目的の場合に、その指定内容を帰るようにしても良い。

図１０は、走行状態判定部１０６のフローを示す。まず、データ圧縮部１０５から渡された車両情報に対して、地図情報管理部１１１に格納されている地図情報から、緯度・経度の位置情報をキーにして道路種別を取得する（ステップ１００１）。渋滞定義管理部１１０から渋滞定義情報（図５）を読み込む（ステップ１００２）。次に、車両情報から平均車速を算出し、ステップ1001で求めた、渋滞定義情報の道路種別501に対応する平均車速502に基づいて、算出した平均車速から渋滞区間を判定する（ステップ１００３）。平均車速は、例えば、前後の１０個のデータの平均値で算出することで求めることができる。前後１分のデータから算出する方法でも良いし、前１０個だけから算出する方法でも良い。また、地図情報から得られる信号機情報から、信号現示に伴う徐行や停止のデータを除き、他の車速データの変化（微係数又は差分）を捉え、低速への変化時点から高速への変化時点の平均車速を求めても良い。次に、道路種別/渋滞区間に基づいて、道路種別/渋滞区間が変わる部分でデータを分割する（ステップ１００４）。渋滞区間は、前述したように、渋滞情報などを提供する道路情報システムから得られた情報に従って渋滞を認識しても良い。

図１１は、車両情報からの、走行状態判定の処理イメージを示す。図１１(A)は図１０のステップ１００１の処理イメージを示す。図１１(A)の日時や座標は車両情報（図３）と同じ情報である(図１１(A)では図が煩雑になるため、表記を簡略化してある。)。ステップ１００１では、座標情報から道路種別を決定する。道路種別は決定され、走行状態のカラムに格納される。この例では、道路種別が「平地」と決定されている。

図１１(B)は図１０のステップ１００３の処理イメージを示す。渋滞定義情報より、平均車速が２０ｋｍ/時以下の車両情報を渋滞と判定する。ここで、図１１(B)の平均車速は、車両情報の車速から計算して求めたものである。

図１１(C)はステップ１００４の処理イメージを示す。道路種別/渋滞区間が変わる部分でデータを分割する。この例では、「平地」が連続する（１）のデータ、「渋滞」が連続する（２）のデータ、「平地」が連続する（３）のデータに分割する。

図１２は、ユーザへの情報提供例を示す。ユーザは、パソコンなどの端末装置からセンタサーバ１２０にアクセスすることで、センタサーバ１２０にアップロードされた圧縮情報を閲覧することができる。情報提供の画面には、走行状態１２０１、燃費の推移１２０２、走行距離の推移１２０３、時刻１２０４が表示される。横軸の目盛りは常に同じ値を示している訳ではなく、車両情報を圧縮するための尺度として「距離」「時間」「区間」の何れかを選択したかによって意味が異なる。１目盛りが１０ｋｍを示していることもあれば、１時間を示していることもある。走行状態１２０１には、一定距離/時間/区間での走行状態や、「区間」の定義に用いられているインターチェンジ、サービスエリアなども表示されている。燃費の推移１２０２には、一定距離/時間/区間での平均燃費の折れ線グラフが表示されている。走行距離の推移１２０３には、一定距離/時間/区間での累積走行距離が棒グラフで表示されている。時刻１２０４は各時点での通過時刻を表している。

図12は、走行状態に応じて変化が顕著に見られる燃費の推移を例示しているが、タイヤの磨耗やその他の部品の磨耗や劣化状況は変化が顕著ではないので、たとえば、1年間などの所定期間または部品交換後の走行状態別の累積走行距離及び累積走行時間を表示する。

ユーザは、パソコンから閲覧するのではなく、携帯電話やＰＤＡなどの携帯端末からアクセスしても良いし、通信機能の付いたカーナビゲーション端末からアクセスしても良い。また、圧縮した車両情報をセンタサーバ１２０にアップロードして閲覧するのではなく、車両情報記録装置１０２に蓄積された情報を、カーナビゲーション端末で直接閲覧しても良いし、無線で接続した携帯電話やＰＤＡなどの携帯端末で閲覧しても良い。

本実施例によれば、走行状態に応じて車両情報の圧縮方法を変更することで、ユーザに求められる車両情報が、他の車両情報との関連を含めて、必要とされる精度で記録され、必要以上の情報や必要以上の精度による記録を排除することにより、車両情報の記録(管理)装置の記憶容量を適正に使用できる。

実施例のシステムの構成を示す。 実施例のハードウェアの構成を示す。 実施例の車両情報管理部のテーブル構成を示す。 実施例の圧縮ルール管理部のテーブル構成を示す。 実施例の渋滞定義管理部のテーブル構成を示す。 実施例の推定ルール管理部のテーブル構成を示す。 実施例の圧縮情報管理部のテーブル構成を示す。 の実施例の車両情報圧縮処理のフローを示す。 実施例の走行目的推定部のフローを示す。 実施例のる走行状況判定部のフローを示す。 実施例の走行状態判定の処理イメージを示す。 実施例のユーザへの情報提供例を示す。

符号の説明

１０１：車両、１０２：車両情報記録装置、１０３：データ収集部、１０４：データ送信部、１０５：データ圧縮部、１０６：走行状態判定部、１０７：走行目的推定部、１０８：車両情報管理部、１０９：圧縮ルール管理部、１１０：渋滞定義管理部、１１１：地図情報管理部、１１２：推定ルール管理部、１１３：圧縮情報管理部、１１４：ＧＰＳ、１１５：ＥＣＵ、１１６：車内ネットワーク、１１７：通信装置、１１８：ナビゲーション端末、１１９：ネットワーク、１２０：センタサーバ。

Claims (13)

1. 車両の走行状態と関連する車両情報を含む、車両搭載機器からの車両情報を取得する車両情報取得手段と、前記取得した車両情報から走行状態を判定する走行状態判定手段と、前記判定した走行状態に対応して、距離、時間及び区間の少なくとも一つの尺度に基づいた、前記取得した車両情報の圧縮方法を決定し、前記車両の走行目的に対応して、前記決定した圧縮方法による、前記車両情報の圧縮率を変更する圧縮方法決定手段と、前記決定した圧縮方法および前記変更した圧縮率で、前記走行状態の区間の前記走行状態と関連する車両情報を含む車両情報を圧縮して、前記圧縮した車両情報を前記走行状態の区間に対応させて記録する車両情報記録手段とを有することを特徴とする車両情報管理装置。
2. 前記区間は、前記車両が走行した道路に関するランドマークで区切られる区間、前記車両が走行した道路種別で区切られる区間、前記車両が走行した道路の渋滞していた区間、及び前記車両の車両状態で定義した区間の少なくとも一つを含む請求項１記載の車両情報管理装置。
3. 前記走行状態判定手段が判定する前記走行状態には、前記車両が走行した道路の道路種別及び前記車両が走行した道路が渋滞していたことを示す情報の少なくとも一つを含むことを特徴とする請求項１記載の車両情報管理装置。
4. 前記道路種別には、一般道の平地、一般道の山道、郊外の一般道、都市部の一般道、郊外の高速道路、及び都市部の高速道路の少なくとも一つを含むことを特徴とする請求項3記載の車両情報管理装置。
5. 車両搭載機器から収集した、車両の走行状態と関連する車両情報を含む、車両情報、距離、時間及び区間の少なくとも一つの尺度に基づいた、前記車両情報を圧縮するための圧縮ルール、及び圧縮した車両情報を格納する記憶装置と、前記記憶装置に格納されている車両情報から前記車両の走行状態を判定し、前記判定した走行状態に基づいて、前記圧縮ルールから前記車両情報の圧縮方法を選択し、前記車両の走行目的に対応して、前記選択した圧縮方法による、前記車両情報の圧縮率を変更し、前記選択した圧縮方法および前記変更した圧縮率で、前記走行状態の区間の前記走行状態と関連する車両情報を含む車両情報を圧縮して、前記圧縮した車両情報を前記走行状態の区間に対応させて、前記圧縮した車両情報として前記記憶装置に格納するプロセッサとを有することを特徴とする車両情報管理装置。
6. 前記区間は、前記車両が走行した道路に関するランドマークで区切られる区間、前記車両が走行した道路種別で区切られる区間、前記車両が走行した道路の渋滞していた区間、及び前記車両の車両状態で定義した区間の少なくとも一つを含む請求項５記載の車両情報管理装置。
7. 前記走行状態には、前記車両が走行した道路の道路種別及び前記車両が走行した道路が渋滞していたことを示す情報の少なくとも一つを含むことを特徴とする請求項５記載の車両情報管理装置。
8. 前記道路種別には、一般道の平地、一般道の山道、郊外の一般道、都市部の一般道、郊外の高速道路、及び都市部の高速道路の少なくとも一つを含むことを特徴とする請求項７記載の車両情報管理装置。
9. 車両に搭載される車両情報管理装置が、前記車両の走行状態と関連する車両情報を含む、車両搭載機器からの車両情報を取得し、前記取得した車両情報から走行状態を判定し、前記判定した走行状態に対応して、距離、時間及び区間の少なくとも一つの尺度に基づいた、前記取得した車両情報の圧縮方法を決定し、前記車両の走行目的に対応して、前記決定した圧縮方法による、前記車両情報の圧縮率を変更し、前記決定した圧縮方法および前記変更した圧縮率で、前記走行状態の区間の前記走行状態と関連する車両情報を含む車両情報を圧縮し、前記圧縮した車両情報を前記走行状態の区間に対応させて記憶装置に記録することを特徴とする車両情報管理方法。
10. 前記区間は、前記車両が走行した道路に関するランドマークで区切られる区間、前記車両が走行した道路種別で区切られる区間、前記車両が走行した道路の渋滞していた区間、及び前記車両の車両状態で定義した区間の少なくとも一つを含む請求項９記載の車両情報管理方法。
11. 前記判定した走行状態には、前記車両が走行した道路の道路種別及び前記車両が走行した道路が渋滞していたことを示す情報の少なくとも一つを含むことを特徴とする請求項９記載の車両情報管理方法。
12. 前記道路種別には、一般道の平地、一般道の山道、郊外の一般道、都市部の一般道、郊外の高速道路、及び都市部の高速道路の少なくとも一つを含むことを特徴とする請求項１１記載の車両情報管理方法。
13. 車両に搭載され、前記車両の車両情報を取得し、前記取得した車両情報を記録する車両情報管理装置に実行させるための車両情報管理プログラムであって、前記車両の走行状態と関連する車両情報を含む、車両搭載機器からの車両情報を取得し、前記取得した車両情報から走行状態を判定し、前記判定した走行状態に対応して、距離、時間及び区間の少なくとも一つの尺度に基づいた、前記取得した車両情報の圧縮方法を決定し、前記車両の走行目的に対応して、前記決定した圧縮方法による、前記車両情報の圧縮率を変更し、前記決定した圧縮方法および前記変更した圧縮率で、前記走行状態の区間の前記走行状態と関連する車両情報を含む車両情報を圧縮し、前記圧縮した車両情報を前記走行状態の区間に対応させて記憶装置に記録することを特徴とする車両情報管理プログラム。

Images