JP2018136921A - 運転支援装置 - Google Patents

Abstract

【課題】運転特性の報知頻度を、ドライバの運転頻度に応じて設定することのできる運転支援装置の提供。【解決手段】操作取得部１３，１５は、車両に対するドライバによる操作状態を取得する。特性取得部１６は、前記操作取得部が取得した操作状態に基づき、前記ドライバの運転特性を取得する。頻度取得部１７は、前記車両に対する前記ドライバによる運転頻度を取得する。報知部１９は、前記頻度取得部が取得した運転頻度に応じた間隔で、前記特性取得部が取得した運転特性に係る情報を前記ドライバに報知する。【選択図】図１

Description

本発明は、ドライバによる車両の運転を支援する技術に関する。なお、本明細書において、運転特性とは、方向指示器を出すタイミングが速い若しくは遅い、先行車両との車間距離が長い若しくは短い、加減速が急若しくは緩慢であるなど、ドライバによる車両の運転操作の特性（すなわち、傾向）であれば、どのような特性であってもよいものとする。

従来、車両を運転するドライバに対し、ドライバの嗜好、癖、能力などによる運転特性を取得し、アドバイス等の形態でドライバに報知する運転支援装置が提案されている。また、このような運転支援装置では、取得された運転特性をどのようなタイミングでドライバに報知するかについても、種々工夫がなされている。例えば、特許文献１には、前回の報知から、一定時間が経過するか、車両が一定距離走行したときに、新たな報知を行うことが提案されている。

特開２０１１−３４４３０号公報

しかしながら、特許文献１に記載のように、一定時間が経過するか車両が一定距離走行したときに報知がなされる場合、ドライバの運転頻度によって報知の効果が異なるという問題が懸念される。例えば、一定時間毎に報知がなされる場合、運転頻度が低いドライバに対しては、例えば運転する度に報知がなされるといった具合に高い頻度で報知がなされる。しかも、その報知の間には、ドライバは殆ど運転を行っていないため、運転特性も変化しておらず、毎回同様の報知がなされることになる。このため、ドライバは報知を煩わしく感じる場合がある。一方、運転頻度が高いドライバに対しては、報知の頻度が低く感じられる場合があり、その報知による安全性向上等の効果も十分に発揮されない場合がある。

本発明は、こうした問題にかんがみてなされたものであり、運転特性の報知頻度を、ドライバの運転頻度に応じて設定することのできる運転支援装置の提供を目的としている。

本発明は、車両の運転を支援するように構成された運転支援装置であって、操作取得部（１３，１５，Ｓ９１）と、特性取得部（１６）と、頻度取得部（１７）と、報知部（１９）と、を備える。

操作取得部は、前記車両に対するドライバによる操作状態を取得するように構成されている。特性取得部は、前記操作取得部が取得した操作状態に基づき、前記ドライバの運転特性を取得するように構成されている。頻度取得部は、前記車両に対する前記ドライバによる運転頻度を取得するように構成されている。報知部は、前記頻度取得部が取得した運転頻度に応じた間隔で、前記特性取得部が取得した運転特性に係る情報を前記ドライバに報知するように構成されている。このような構成によれば、特性取得部が取得したドライバの運転特性に係る情報の報知頻度を、頻度取得部が取得した運転頻度に応じた間隔に設定することができる。

なお、この欄及び特許請求の範囲に記載した括弧内の符号は、一つの態様として後述する実施形態に記載の具体的手段との対応関係を示すものであって、本発明の技術的範囲を限定するものではない。

本発明を適用した運転支援装置の構成を表すブロック図である。 その運転支援装置の制御ユニットによる処理を表すフローチャートである。 その処理のうちの特性診断処理を詳細に表すフローチャートである。

以下、図面を参照しながら、発明を実施するための形態を説明する。
［１．第１実施形態］
［１−１．構成］
図１に示す運転支援装置１は、車両（以下、自車）に搭載されており、制御ユニット１０を中心に構成されている。制御ユニット１０は、地図データベース１１と、図示省略したＣＰＵと、図示省略したＲＡＭ，ＲＯＭ，フラッシュメモリ等の半導体メモリと、を有する周知のマイクロコンピュータを中心に構成される。制御ユニット１０の各種機能は、前記ＣＰＵが非遷移的実体的記録媒体に格納されたプログラムを実行することにより実現される。この例では、前記半導体メモリが、プログラムを格納した非遷移的実体的記録媒体に該当する。また、このプログラムの実行により、プログラムに対応する方法が実行される。なお、制御ユニット１０を構成するマイクロコンピュータの数は１つでも複数でもよい。

制御ユニット１０は、ＣＰＵがプログラムを実行することで実現される機能の構成として、図１に示すように、自車位置情報取得部１２と、ドライバ状態推定部１３と、ドライバ特定部１４と、運転シーン推定部１５と、運転特性診断部１６と、運転頻度推定部１７と、記憶部１８と、報知部１９と、を備える。なお、図１において、地図データベースは地図ＤＢと略記し、自車位置情報取得部は自車位置情報と略記している。制御ユニット１０を構成するこれらの要素を実現する手法はソフトウェアに限るものではなく、その一部又は全部の要素を、論理回路やアナログ回路等を組み合わせたハードウェアを用いて実現してもよい。

自車位置情報取得部１２は、自車に設けられたＧＰＳアンテナ２０から、自車の位置を表す情報を取得する。なお、自車位置情報取得部１２は、ＧＰＳ以外の規格のＧＮＳＳを用いた方法、ジャイロセンサ用いた方法、マップマッチングを用いた方法、路側器との通信を用いた方法等、他の方法によって自車の位置を表す情報を取得してもよい。ここで、ＧＰＳとは、グローバル・ポジショニング・システムの略である。また、ＧＮＳＳとは、グローバル・ナビゲーション・サテライト・システムの略である。

ドライバ状態推定部１３は、自車の運転席に設けられたドライバカメラ３０が撮影したドライバの顔の画像を取得して、画像解析によりドライバの状態（例えば、脇見の有無、眠気の有無等）を推定する。

ドライバ特定部１４は、前述のドライバカメラ３０、及び、ドライバが所持する携帯電話４０、及び、運転席に係るシートメモリ５０から、情報を取得してドライバを特定する。例えば、ドライバ特定部１４は、ドライバカメラ３０が撮影したドライバの顔の画像を画像解析して、周知の顔認証の手法によりドライバを特定してもよい。

また、ドライバ特定部１４は、携帯電話４０が自車に有線接続されたときに通信を介して取得される情報に基づいてドライバを特定してもよい。また、ドライバ特定部１４は、携帯電話４０と自車とがＢｌｕｅｔｏｏｈ（登録商標）等の規格による無線通信を介して接続されたときに取得される情報に基づいてドライバを特定してもよい。なお、これらの場合、携帯電話４０の代わりに、タブレット端末やノートパソコン等の他の携帯端末が用いられてもよい。また、携帯端末はスマートキーであってもよく、携帯電話４０自身がスマートキーとして機能するものであってもよい。

また、ドライバが自身の希望する運転席の位置をシートメモリ５０に登録している場合は、当該登録された位置がシートメモリ５０から読み出されて、その位置に運転席が配置されているか否かに基づいて、ドライバ特定部１４はドライバを簡易的に特定してもよい。

更に、ドライバ特定部１４は、これらの特定方法のいずれか１つを実行してもよく、複数の特定方法を実行して総合的にドライバを特定してもよい。総合的にドライバを特定する方法は、各特定方法に重み付けをして合算する方法や、単純に多数決を行う方法など、周知の種々の方法が適用可能である。また、ドライバ特定部１４は、ドライバの顔の画像とも携帯端末からの情報ともシートメモリ５０からの情報とも異なる他の情報（例えば、ドライバの指紋の画像）に基づいてドライバを特定してもよい。

運転シーン推定部１５は、地図データベース１１に記憶されている地図データ、自車位置情報取得部１２が取得した自車の位置、及び、車両情報取得部６０が取得した車両情報などに基づいて、自車の走行状況を表す運転シーンを判定する。なお、車両情報取得部６０は、自車の状態を検出するもので、１つ又は複数のセンサによって構成される。この車両情報取得部６０は、方向指示器の操作状態、アクセル開度、ブレーキの操作状態、舵角、及び、周辺情報のうち、少なくとも１つを車両情報として取得する。ここで、周辺情報とは、例えば、先行車との車間距離、自車周辺における障害物の有無、白線又は黄線又は鋲等の境界線の位置などである。運転シーン推定部１５では、例えば、自車が交差点を左折した場合には「左折シーン」、自車が交差点を右折した場合には「右折シーン」、といったように、走行状況毎の運転シーンを推定（すなわち、判定）する。なお、図１において、車両情報取得部は車両情報と略記している。

運転特性診断部１６は、運転シーン推定部１５が推定した運転シーンと、車両情報取得部６０が取得した車両情報とに基づいてドライバの運転特性（例えば、癖）を取得する。例えば、運転特性診断部１６は、車両の状態を所定の評価項目について評価し、ドライバの運転操作の傾向を表す運転特性を診断することによって、当該運転特性を取得してもよい。また、運転特性診断部１６は、運転特性を診断する際、ドライバ状態推定部１３が推定したドライバの状態（例えば、脇見の有無、眠気の有無等）を参照してもよい。更に、ドライバ状態推定部１３が、ドライバの状態として殺気立っているとか穏やかな表情であるとかいった状態を取得可能な場合、運転特性診断部１６は、苛立ちや焦りの有無も運転特性として取得してもよい。

運転頻度推定部１７は、ドライバ特定部１４が特定したドライバに対して、自車に対する当該ドライバによる運転頻度を取得する。運転頻度推定部１７は、ドライバ特定部１４が、自車のドライバが特定の１人の人物（例えば、自車の所有者）であると特定した場合に、そのドライバによる運転頻度を計数するなどして取得してもよい。その場合、運転頻度推定部１７は、当該ドライバによる運転頻度を記憶部１８に記憶する。また、記憶部１８には、運転特性診断部１６によって取得された当該ドライバの運転特性が、当該ドライバによる運転頻度と対応付けて記憶される。

また、運転頻度推定部１７は、自車のドライバが、予め登録された複数の人物のいずれかであると特定した場合に、運転頻度をドライバ毎に計数するなどして取得してもよい。その場合、運転頻度推定部１７は、各ドライバに割り当てられたＩＤ等の識別情報と、当該ドライバによる運転頻度とを対応付けて記憶部１８に記憶する。その場合、記憶部１８には、運転特性診断部１６によって取得された当該ドライバの運転特性が、当該ドライバ係る識別情報及び運転頻度と対応付けて記憶される。なお、前記登録は、ドライバ特定部１４が新たに別人をドライバとして特定する毎に追加登録がなされてもよい。以下、この場合を例にとって説明する。

報知部１９は、運転特性診断部１６が取得した運転特性に係る情報を、運転頻度推定部１７が取得した運転頻度に応じた間隔で、自車のドライバに報知する。報知部１９は、自車の運転席前方に設けられた表示部７０（例えば、液晶ディスプレイ）に駆動信号を出力して、前記情報に応じた文字または映像を表示することによって、前記情報を報知してもよい。また、報知部１９は、自車の車室内に設けられた音声出力部８０（例えば、スピーカ）に駆動信号を出力して前記情報を発声させることによって、前記情報を報知してもよい。

また、前記報知は、運転シーン推定部１５によって判定された運転シーンが、運転負荷の低い運転シーンとなったタイミングでなされてもよい。運転負荷が低いか否かは、運転負荷の低い運転シーンとして予め登録された運転シーンであるか否かに基づいて判断されてもよい。また、運転負荷が低いか否かは、運転シーン毎に運転負荷を数値化しておき、その時点における運転負荷が予め設定された所定値以下であるかに基づいて判断されてもよく、その他の方法で判断されてもよい。

［１−２．処理］
次に、制御ユニット１０が実行する処理について、図２のフローチャートを用いて説明する。なお、この処理は、制御ユニット１０に備えられたＣＰＵが、同じく制御ユニット１０に備えられたＲＯＭに記憶されたプログラムに基づいて、自車の電源がオンである間に所定間隔で繰り返し実行する。

図２に示すように、この処理では、先ず、Ｓ１にて、ドライバの顔の画像又は携帯電話４０からの情報又はシートメモリ５０からの情報等のドライバ情報が取得され、続くＳ３にて、当該ドライバ情報に基づいて自車のドライバが特定される。前述のように、これらはドライバ特定部１４としての処理である。

続くＳ５では、Ｓ３にて特定されたドライバが既に登録されたドライバであるか否かが判断される。既に登録されたドライバでない場合は、Ｓ５にてＮＯと判断されて、処理はＳ７へ移行する。Ｓ７では、Ｓ３にて特定された前記ドライバが新規のドライバとして情報登録された後、処理はＳ９へ移行する。なお、Ｓ７における情報登録とは、ドライバの顔の画像又は携帯電話４０からの情報又はシートメモリ５０からの情報等の、ドライバを特定するための情報と、当該ドライバに割り当てたＩＤ等の識別情報とを、記憶部１８に記憶する処理であってもよい。その場合、ドライバ特定部１４は、記憶部１８に記憶された前記特定するための情報と識別情報とのデータセットを参照して、Ｓ３の処理としてのドライバの特定を行う。

一方、Ｓ５にて、Ｓ３にて特定されたドライバが既に登録されたドライバである（すなわち、ＹＥＳ）と判断された場合は、処理はＳ１１へ移行し、当該ドライバに係る過去の診断情報（すなわち、既に取得された運転特性）が取得された後、処理はＳ９へ移行する。Ｓ９では、図３に詳細に示す特性診断処理が実行される。

この処理では、図３に示すように、先ず、運転シーン推定部１５及び運転特性診断部１６としての処理であるＳ９１にて、車両情報取得部６０から前述の車両情報が取得される。続いて、自車位置情報取得部１２としての処理であるＳ９２が実行されることにより、自車の位置を表す情報が取得される。続いて、運転シーン推定部１５としての処理であるＳ９３が実行されることにより、自車の運転シーンが判定される。続いて、ドライバ状態推定部１３としての処理であるＳ９４が実行されることにより、ドライバの状態が推定される。

続いて、運転特性診断部１６としての処理であるＳ９５が実行されることにより、ドライバの運転特性が診断される。例えば、ドライバの加速や減速の仕方、先行車との車間距離の空け具合などの、癖や傾向が診断される。なお、運転特性としては、例えば特許文献１に記載のような、周知の各種運転特性が診断されてもよい。続くＳ９６では、Ｓ９５にて診断された運転特性が記憶部１８に記憶され、処理は図２のＳ１３へ移行する。

Ｓ１３では、Ｓ９６の処理によって記憶部１８に記憶された運転特性の診断結果が、運転特性の診断結果としてドライバに出力可能な程度に蓄積されているか否かが判断される。ドライバの運転特性に対する診断は、ドライバの癖や傾向に係る診断であるため、１トリップでは結果が出ない場合がある。なお、１トリップとは、電源がオンされて運転が開始されてから電源がオフされて運転が終了されるまでをいう。１つ１つの運転特性は、走行する道路種別及び形状及び交通状況にもよるが、２０時間〜３０時間ほどで、運転特性の診断結果を出力することができる。なお、２０時間〜３０時間ほどで運転特性は丸ごと更新される。例えば、週５回往復１時間運転する人に対しては、その人が運転を始めて１か月程度診断結果がたまって、初めてある程度信頼できる診断結果が出力可能となる。Ｓ１３では、そのようにある程度信頼できる診断結果が出力可能な程度に、記憶部１８に運転特性の診断結果が十分に蓄積されているか否かが判断される。そして、十分に蓄積されていない場合は、Ｓ１３にてＮＯと判断されて、処理はそのまま一旦終了する。

なお、ある程度信頼できる診断結果が出力可能な程度に記憶部１８に運転特性の診断結果が蓄積された後は、記憶部１８には、新たにＳ９６の処理によって運転特性の診断結果が記憶されるたびに、最も古い診断結果が記憶部１８から消去される。このため、運転特性の診断結果は、Ｓ９の特性診断処理が実行されるたびに変化していく。

ある程度信頼できる診断結果が出力可能な程度に、運転特性の診断結果が十分に蓄積されている（すなわち、ＹＥＳ）と、Ｓ１３にて判断された場合は、処理はＳ１５へ移行する。運転頻度推定部１７としての処理であるＳ１５では、現在自車を運転しているドライバによる自車に対する運転頻度が取得される。続くＳ１７では、Ｓ１５にて取得された運転頻度に応じて、運転特性をアドバイスとして報知（すなわち、出力）する期間Ａが日単位で算出される。例えば、毎日通勤で（すなわち、週１０回）運転しているドライバには１か月毎に、週末に２回程度（すなわち、往復で週４回）運転しているドライバには２か月毎に通知するといったように、Ｓ１７では、運転特性をアドバイスする定期通知の期間Ａが、運転頻度に応じて変更される。

続くＳ１９では、前回に運転特性をアドバイスとして報知した日Ｂが取得され、続くＳ２１にて、現在日がＡ＋Ｂ以上であるか否か、すなわち、現在日が、前記期間Ａを前記報知した日Ｂに加えた日に達しているか否かが判断される。現在日がＡ＋Ｂ未満である場合は、Ｓ２１にてＮＯと判断されて、処理はそのまま一旦終了する。一方、現在日がＡ＋Ｂ以上である場合は、Ｓ２１にてＹＥＳと判断されて、処理はＳ２３へ移行する。なお、日時はＧＰＳアンテナ２０に係るシステムから取得できるが、自車がＧＰＳアンテナを備えていない場合は車両に設定された時間が使われてもよい。

Ｓ２３では、運転シーン推定部１５としての処理（例えば、Ｓ９３）によって判定された運転シーンに基づいて、運転負荷が推定される。続くＳ２５では、Ｓ２３にて推定された運転負荷が低いか否かが判断される。すなわち、Ｓ２３，Ｓ２５の処理では、運転負荷の状況が、車両情報やドライバ情報や地図情報を参照することにより、現在ドライバへ報知をしても安全な状況かどうかが推定される。運転負荷が低い状態とは、例えば信号で停止中の状態や、高速道路のまっすぐな区間を走行中で先行車も無い状態などが考えられる。一方、運転負荷が高い状態としては、駐車中や渋滞中などが考えられる。

このように、運転負荷が低いか否かは、運転負荷の低い運転シーンとして予め登録された運転シーンであるか否かに基づいて判断されてもよい。なお、運転負荷が低いか否かは、運転シーン毎に運転負荷を数値化しておき、その時点における運転負荷が予め設定された所定値以下であるかに基づいて判断されてもよく、その他の方法で判断されてもよい。

運転負荷が低くない場合は、Ｓ２５にてＮＯと判断されて、処理はそのまま一旦終了する。一方、運転負荷が低い場合は、Ｓ２５にてＹＥＳと判断されて、処理はＳ２７へ移行する。Ｓ２７では、当該ドライバの運転特性がアドバイスとして報知され、続くＳ２９では、当該報知がなされた日が記憶されて、処理が一旦終了する。

［１−３．効果］
以上詳述した第１実施形態によれば、以下の効果が得られる。
（１Ａ）本実施形態では、Ｓ１５にて取得された運転頻度に応じた間隔（すなわち、期間Ａ）で、運転特性がアドバイスとして報知される。このため、ドライバには、報知が煩わしく感じられる可能性も低く、かつ、報知による安全性向上等の効果も十分に期待できる適切な間隔に、運転特性の報知頻度を設定することができる。

（１Ｂ）また、前記運転頻度は、所定期間としての１週間当たりにドライバが自車を運転した回数であり、前記間隔は、前記回数に応じて算出される日数である。このため、ドライバが自車を一定時間運転する毎に報知がなされる場合に比べて、次のような効果が生じる。

例えば、長時間継続的に運転がなされた場合、一定時間運転する毎に報知がなされる場合は、１トリップ中に何度も報知がなされる可能性がある。その場合、渋滞中に何度も報知がなされると、ドライバは報知を煩わしく感じる可能性がある。これに対し、本実施形態のように、所定期間当たりに運転がなされた回数（すなわち、トリップ数）に応じて報知がなされる間隔が日単位で設定されれば、そのような事態を回避することができる。また、短時間の運転であっても、例えば通勤のように同じ道を何度もドライバが自車を運転する場合は、本実施形態のようにトリップ数に応じた間隔で報知がなされた方が、安全性向上の効果が高い場合がある。なお、前記所定期間は１０日，１月などといった他の期間であってもよい。

（１Ｃ）しかも、前記間隔は、前記回数が多いほど短い日数として算出され、かつ、前記回数と前記日数との積は、前記回数が多いほど大きい値となるように、前記日数が算出される。このため、前記積が一定値となるように前記日数が算出される場合に比べて、運転頻度が極めて少ないドライバに対する運転特性の報知間隔が長くなりすぎるのを抑制することができる。例えば、下記の表１に示すように、頻度（すなわち、１週間当たりにドライバが自車を運転した回数）が０．１回のドライバに対しては、積が３００で一定の場合は３０００日に１度しか報知がなされない。これに対し、回数が多いほど積が大きい値となる場合、表１の例では２０日〜１００日間隔で、全てのドライバが運転頻度に応じた間隔で報知を受けることができる。

（１Ｄ）本実施形態では、最初のＳ１，Ｓ３の処理によってドライバが所定人物（例えば、識別情報が割り当てられた１人又は複数の人物）であるか否かを判定し、当該所定人物であると判定されたドライバに対して各処理が実行される。このため、自車が何人かのドライバによって運転される場合も、当該所定人物としてのドライバに応じて適切に運転特性を取得して、当該ドライバに適切に当該運転特性を報知することができる。

［１−４．特許請求の範囲の要素との対応］
なお、前記第１実施形態において、運転特性診断部１６におけるＳ９１の処理及びドライバ状態推定部１３及び運転シーン推定部１５は操作取得部に対応する。また、運転特性診断部１６は特性取得部に対応する。また、運転頻度推定部１７は頻度取得部に対応する。また、ドライバ特定部１４はドライバ判定部に対応する。また、携帯電話４０は携帯端末に対応する。

［２．他の実施形態］
以上、本発明を実施するための形態について説明したが、本発明は上述の実施形態に限定されることなく、種々変形して実施することができる。

（２Ａ）前記第１実施形態では、車両情報取得部６０及び運転シーン推定部１５及びドライバ状態推定部１３から、自車に対するドライバによる操作状態が取得されたが、これに限定されるものではない。例えば、操作状態は、前記３者のうちのいずれか１つ又は２つから取得されてもよく、それ以外の方法で操作状態が取得されてもよい。例えば、ドライバの心拍数や、ステアリングホイールが握られる圧力等が参照されてもよく、更に他のパラメータが参照されてもよい。

（２Ｂ）前記第１実施形態では、運転頻度に応じた期間Ａが日単位で算出されたが、これに限定されるものではない。例えば、前記期間Ａは時間単位で算出されてもよく、秒単位で算出されてもよい。その場合、報知日Ｂは報知時刻とされる。

（２Ｃ）前記第１実施形態では、ドライバ特定部１４を介してドライバが特定されたが、これに限定されるものではない。例えば、自車のドライバは常に特定の人物（例えば所有者）であるとみなして、ドライバ特定部１４及びそれに係る処理が省略されてもよい。

（２Ｄ）前記実施形態における１つの構成要素が有する複数の機能を、複数の構成要素によって実現したり、１つの構成要素が有する１つの機能を、複数の構成要素によって実現したりしてもよい。また、複数の構成要素が有する複数の機能を、１つの構成要素によって実現したり、複数の構成要素によって実現される１つの機能を、１つの構成要素によって実現したりしてもよい。また、前記実施形態の構成の一部を省略してもよい。また、前記実施形態の構成の少なくとも一部を、他の前記実施形態の構成に対して付加又は置換してもよい。なお、特許請求の範囲に記載した文言のみによって特定される技術思想に含まれるあらゆる態様が本発明の実施形態である。

（２Ｅ）上述した運転支援装置の他、当該運転支援装置を構成要素とするシステム、当該運転支援装置としてコンピュータを機能させるためのプログラム、このプログラムを記録した半導体メモリ等の非遷移的実態的記録媒体、運転支援方法など、種々の形態で本発明を実現することもできる。

１…運転支援装置 １０…制御ユニット １２…自車位置情報取得部
１３…ドライバ状態推定部 １４…ドライバ特定部 １５…運転シーン推定部
１６…運転特性診断部 １７…運転頻度推定部 １９…報知部
２０…ＧＰＳアンテナ ３０…ドライバカメラ ４０…携帯電話
５０…シートメモリ ６０…車両情報取得部

Claims (7)

1. 車両の運転を支援するように構成された運転支援装置であって、
   前記車両に対するドライバによる操作状態を取得するように構成された操作取得部（１３，１５，Ｓ９１）と、
   前記操作取得部が取得した操作状態に基づき、前記ドライバの運転特性を取得するように構成された特性取得部（１６）と、
   前記車両に対する前記ドライバによる運転頻度を取得するように構成された頻度取得部（１７）と、
   前記頻度取得部が取得した運転頻度に応じた間隔で、前記特性取得部が取得した運転特性に係る情報を前記ドライバに報知するように構成された報知部（１９）と、
   を備えた運転支援装置。
2. 請求項１に記載の運転支援装置であって、
   前記運転頻度は、所定期間当たりに前記ドライバが前記車両を運転した回数であり、
   前記間隔は、前記回数に応じて算出される日数である運転支援装置。
3. 請求項２に記載の運転支援装置であって、
   前記日数は、前記回数が多いほど短い日数として算出され、かつ、前記回数と前記日数との積は、前記回数が多いほど大きい値となるように、前記日数が算出される運転支援装置。
4. 請求項１〜３のいずれか１項に記載の運転支援装置であって、
   前記車両のドライバが所定人物であるか否かを判定するドライバ判定部（１４）
   を、更に備え、
   前記操作取得部、前記特性取得部、前記頻度取得部、及び、前記報知部は、前記ドライバ判定部によって前記所定人物であるとして判定されたドライバに対して、前記取得又は報知を行うように構成された運転支援装置。
5. 請求項４に記載の運転支援装置であって、
   前記ドライバ判定部は、前記車両のドライバの顔を撮影した画像に基づいて、前記ドライバが前記所定人物であるか否かを判定するように構成された運転支援装置。
6. 請求項４に記載の運転支援装置であって、
   前記ドライバ判定部は、前記車両のドライバが所持する携帯端末（４０）との通信により、前記ドライバが前記所定人物であるか否かを判定するように構成された運転支援装置。
7. 請求項４に記載の運転支援装置であって、
   前記ドライバ判定部は、前記車両の運転席が前記車両のドライバによって設定された位置にあるか否かに基づいて、前記ドライバを特定する運転支援装置。

Images