(57)【要約】【課題】運転者の負荷をより高精度に推定して運転者に対する情報の報知を行うことのできる車両用情報報知装置を提供する。【解決手段】車両状態推定部Ｍ１２は、直進走行時よりも、右折や左折をしているときの方が負荷が大きいと演算する。ドライバ状態推定部Ｍ１４は、運転者の最終運転日時と現在時との間隔が長い場合には、短い場合と比較して、今回の運転にかかる負荷が大きいと演算する。周辺状態推定部Ｍ１６は、走行する道路を運転者が以前に走行したことがない場合、走行したことがある場合と比較して、運転にかかる負荷が大きいと演算する。統合状態判定部Ｍ１８は、車両状態推定部Ｍ１２や、ドライバ状態推定部Ｍ１４、周辺状態推定部Ｍ１６の演算する負荷に基づき最終的な負荷を演算し、これに基づき報知する情報の内容やタイミングを決定する。【選択図】図１
2016013753.tif 000002
【特許請求の範囲】
【請求項１】
運転者の精神的な負荷を演算し、その負荷に応じて運転者に報知する内容およびタイミングの少なくとも一方を変更する車両用情報報知装置において、
前回の運転終了時から今回の運転開始時までの期間が長い場合、前記期間が短い場合と比較して、前記負荷を大きい値に演算することを特徴とする車両用情報報知装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、車両用情報報知装置に関する。
【背景技術】
【０００２】
たとえば特許文献１には、車両の走行速度や加速度等の値やクラクション頻度に基づき、運転者の精神状態を特性値として定量評価する装置が提案されている。この装置は、特定値に基づき、情報を報知する必要性を判断し、必要な情報のみを報知するものである。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００１−０７１８３３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
上記装置によれば、運転者にかかっている精神的な負荷を、上記特性値として算出し、これに基づき情報の報知を行うことで、運転者にかかっている精神的な負荷に応じた情報の報知を行うことが可能となる。ただし、運転者の負荷は、車両の走行速度等の値やクラクション頻度のみによって定まるものではなく、運転頻度等にも依存する。すなわち、毎日運転している場合と、前回の運転終了時から１月経過している場合とでは、後者の方が運転者にかかる精神的な負荷が大きいと考えられる。
【０００５】
本発明は、そうした実情に鑑みてなされたものであり、その目的は、運転者の負荷をより高精度に推定して運転者に対する情報の報知を行うことのできる車両用情報報知装置を提供することにある。
【課題を解決するための手段】
【０００６】
以下、上記課題を解決するための手段およびその作用効果について記載する。
技術的思想１：運転者の精神的な負荷を演算し、その負荷に応じて運転者に報知する内容およびタイミングの少なくとも一方を変更する車両用情報報知装置において、前回の運転終了時から今回の運転開始時までの期間が長い場合、前記期間が短い場合と比較して、前記負荷を大きい値に演算することを特徴とする車両用情報報知装置。
【０００７】
たとえば、毎日の出勤に車両を利用する場合、その車両の利用は運転者にとって慣れたものとなる。これに対し、普段、車両を運転しない人がレンタカー等を利用して遠方の地に移動する場合には、運転自体が日常の作業ではないことに加えて、見知らぬ土地へと車両を走行させるために、車両の運転が運転者にとって重荷となりやすい。上記装置では、こうした点を踏まえて、前回の運転時から今回の運転時までの期間が長い場合には、期間が短い場合と比較して、運転者が車両を運転する際にかかる負荷を大きい値に演算する。このため、運転履歴に応じて運転者の精神的な負荷を定量評価することができることから、より実態に沿った負荷を演算することができ、ひいては演算負荷をより高精度に推定することができる。
【図面の簡単な説明】
【０００８】
【図１】一実施形態にかかるシステム構成図。
【図２】同実施形態にかかる利用頻度ＤＢに格納されるデータの項目を示す図。
【図３】上記実施形態にかかるドライバ状態推定部の処理の手順を示す流れ図。
【図４】同実施形態にかかる評価手法を示す図。
【図５】同実施形態にかかる走行頻度ＤＢに格納されるデータの項目を示す図。
【図６】上記走行履歴ＤＢのリンクＩＤを模式的に示す図。
【図７】同実施形態にかかる負荷の演算結果を例示するタイムチャート。
【発明を実施するための形態】
【０００９】
以下、車両用情報報知装置の一実施形態について、図面を参照しつつ説明する。
図１に、本実施形態にかかるシステム構成を示す。図１に示すように、本実施形態にかかる車両は、車載ローカル・エリア・ネットワーク（車載ＬＡＮ）を備えている。車載ＬＡＮには、自車位置情報検出部１０、周辺物体検出部１２、ウィンカ１４、道路交通情報通信システム１６、ワイパ１８、狭域通信部２０、舵角センサ２２、ヨーレートセンサ２４、自動料金支払システム２６、加速度センサ２８、車速センサ３０、拡張情報取得部３２、情報提供部３４、および状態推定ＥＣＵ６０が接続されている。
【００１０】
ここで、自車位置情報検出部１０は、ＧＰＳ衛星からの信号に基づき現在値を特定するナビゲーションシステム等によって構成されるものである。周辺物体検出部１２は、車載カメラや赤外線カメラ等の周辺監視カメラ４６や、ミリ波レーダ４８などの外部の物体を感知する装置の出力データに基づき、自車両周辺の物体の有無やその距離を検出する。拡張情報取得部３２は、携帯電話の着信の有無、電子メールの受信の有無、ネットワーク上のニュースサイトから配信されるニュース等を取得する。情報提供部３４は、自車位置情報検出部１０を構成するナビゲーションシステムからの情報や、拡張情報取得部３２によって取得された情報を運転者に提供する。
【００１１】
状態推定ＥＣＵ６０は、運転者の精神的な負荷を演算し、負荷に基づき情報提供部３４を介して運転者に提供する情報を決定する電子制御装置である。図１においては、状態推定ＥＣＵ６０内の処理の一部を、機能ブロック図として示している。
【００１２】
すなわち、状態推定ＥＣＵ６０は、車両情報取得部Ｍ１０、車両状態推定部Ｍ１２、ドライバ状態推定部Ｍ１４、周辺状態推定部Ｍ１６、および統合状態判定部Ｍ１８を備えている。
【００１３】
車両情報取得部Ｍ１０は、車載ＬＡＮを介して、車両に関する様々な情報を取得する。
車両状態推定部Ｍ１２は、車両情報取得部Ｍ１０から取得される情報に基づき車両の挙動を把握し、これに基づき運転者の精神的な負荷を演算する。すなわち、たとえば舵角センサ２２によって検出される舵角や、ウィンカ１４からの信号、自車位置情報検出部１０からの情報等に基づき、車両が右折や左折していることや車線変更していることを把握する。そして、車両が右折や左折している場合や車線変更している場合には、直進走行している場合と比較して運転者の精神的な負荷が大きいと考えられるため、直進走行している場合と比較して負荷を大きい値に演算する。また、周辺物体検出部１２からの情報に基づき、車両の付近に障害物が存在するか否かを把握する。そして、障害物が存在する場合には、存在しない場合と比較して運転者の精神的な負荷が大きいと考えられるため、直進走行している場合と比較して負荷を大きい値に演算する。
【００１４】
ドライバ状態推定部Ｍ１４は、運転者の顔の画像を撮影するドライバモニタカメラ４０や、運転者の脈拍、脳波などを検出する生体センサ４２等からの情報に基づき、運転者の状態、すなわち、運転に集中している度合いや、緊張の度合いを把握する。そして、ドライバ状態推定部Ｍ１４は、これらを踏まえつつ、後述する処理によって運転者の精神的な負荷を演算する。
【００１５】
周辺状態推定部Ｍ１６は、周辺監視カメラ４６やミリ波レーダ４８、各種センサ５０、周辺物体検出部１２からの情報に基づき、周辺車両の有無や交通量、さらには歩行者の有無などを推定するとともに、自車位置情報検出部１０からの情報に基づき自車位置情報を把握する。そして、周辺状態推定部Ｍ１６は、これらを踏まえつつ、後述する処理によって運転者の精神的な負荷を演算する。
【００１６】
統合状態判定部Ｍ１８は、車両状態推定部Ｍ１２によって演算される負荷や、ドライバ状態推定部Ｍ１４によって演算される負荷、さらには周辺状態推定部Ｍ１６によって演算される負荷に基づき、情報提供部３４を介して運転者に提供する情報の内容や提供するタイミングを設定する。
【００１７】
次に、ドライバ状態推定部Ｍ１４の処理の詳細を示す。
ドライバ状態推定部Ｍ１４は、利用頻度ＤＢ４４に格納されたデータに基づき、運転者の精神的な負荷を演算する。
【００１８】
図２に、利用頻度ＤＢ４４に格納されているデータを示す。図２に示すように、利用頻度ＤＢ４４には、鍵情報（ＭｙＫｅｙＩＤ）毎に、最終運転日時、連続運転日数、運転マインド、および評価に関するデータが格納されている。ここで、鍵情報とは、運転者を識別する情報である。鍵情報は、運転者が車両の正当なユーザであることを認証するためにユーザが所持する携帯機等の出力信号から取得される。最終運転日時は、最新の運転終了日時を示す。連続運転日数は、連続して運転をした日数であって且つ、最終運転日を含む日数を示す。運転マインドは、運転者の気分がポジティブであるかネガティブであるかの２値の値として定量化した値を示す。評価は、今回の運転における運転者の精神的な負荷を運転履歴に基づき定量化したものである。
【００１９】
図３に、ドライバ状態推定部Ｍ１４によって実行される処理の手順を示す。この処理は、たとえば車両の認証が完了することをトリガとして実行される。
この一連の処理において、ドライバ状態推定部Ｍ１４は、まず、鍵情報を取得する（Ｓ１０）。次に、ドライバ状態推定部Ｍ１４は、前回の運転終了時からの運転間隔を算出する（Ｓ１２）。この処理は、利用頻度ＤＢ４４に格納されている最終運転日時のうち、ステップＳ１０において取得した鍵情報に対応するものから得られる日時と現在の日時との差を算出する処理となる。続いて、ドライバ状態推定部Ｍ１４は、連続運転日数を算出する（Ｓ１４）。この処理は、まず最終運転日と本日とに基づき、利用頻度ＤＢ４４に格納されている連続運転日数を更新するべきか否かを判断し、必要に応じて更新する値を算出する処理となる。すなわち、最終運転日と本日とが同一である場合には更新する必要がないと判断する一方、最終運転日と本日とが１日以上ずれている場合には更新する必要があると判断する。更新する必要がある場合、最終運転日と本日とが１日ずれているなら、連続運転日数を１日増加補正する一方、２日以上ずれているなら、連続運転日数を０とする。
【００２０】
次に、ドライバ状態推定部Ｍ１４は、利用頻度ＤＢ４４における運転マインドを更新するための処理を実行する（Ｓ１６）。ここでは、ドライバ状態推定部Ｍ１４が、運転者とのインターフェースを用いて運転者に気分がポジティブであるかネガティブであるかを問い、これに答えるように要求する処理を実行する。そして、ドライバ状態推定部Ｍ１４は、運転者がポジティブであるかネガティブであるかの情報を取得すると、この情報は、統合状態判定部Ｍ１８において、上記利用頻度ＤＢ４４の評価から得られる負荷を重み付けするのに用いられる。次に、ドライバ状態推定部Ｍ１４は、ステップＳ１２において算出した運転間隔やステップＳ１４において算出した連続運転日数に基づき、運転者の精神的な負荷を定量評価する（Ｓ１８）。この評価は、図４に示す関係情報を予め記憶しておき、この情報を参照することで実行される。
【００２１】
図４に、抑制機能変化要素と、評価との関係情報を示す。ここで、抑制機能変化要素は、運転履歴情報を分類したものであり、評価は、抑制機能変化要素に対応した負荷の定量評価値である。図においては、評価の値が低いほど、負荷が大きいことを示している。すなわちたとえば、前回運転終了時からの経過時間が１日以上１０日未満の場合の評価（０）よりも、前回運転終了時から「３０」日以上経過している場合の評価（−３）の方が数値を低く設定することで、精神的な負荷がより大きいことを示す。なお、精神的な負荷が大きい場合、情報の報知が制限されることが多いため、情報報知の抑制という意味で、運転履歴情報を抑制機能変化要素とした。
【００２２】
次にドライバ状態推定部Ｍ１４は、連続運転日数や、運転マインド、評価を利用頻度ＤＢ４４に格納する（Ｓ２０）。この処理は、連続運転日数や、運転マインド、評価が既に利用頻度ＤＢ４４に格納されている場合には、これらを更新する処理となる。なお、車両の走行が終了した時点では、さらに、利用頻度ＤＢ４４に格納されている最終運転日時を更新する。そして、ドライバ状態推定部Ｍ１４は、利用頻度ＤＢ４４に格納する処理が完了する場合、この一連の処理を一旦終了する。
【００２３】
ドライバ状態推定部Ｍ１４は、利用頻度ＤＢ４４の運転マインドや評価を更新する場合、それらをドライバ状態推定部Ｍ１４の演算した負荷情報として、統合状態判定部Ｍ１８に出力する。なお、ドライバ状態推定部Ｍ１４は、運転マインドや評価に加えて、上記ドライバモニタカメラ４０や生体センサ４２の出力値に基づき演算される負荷を、統合状態判定部Ｍ１８に適宜出力する。
【００２４】
次に、周辺状態推定部Ｍ１６によって実行される処理について詳述する。周辺状態推定部Ｍ１６は、走行履歴ＤＢ５２に基づき、運転者の精神的な負荷を演算する。走行履歴ＤＢ５２は、車両が走行しようとする道路について、運転者がその道路を走行することに慣れているか否か応じて精神的な負荷を算出するために用いられるデータベースである。
【００２５】
図５に、走行履歴ＤＢ５２に格納されるデータを例示する。図５に示されるように、走行履歴ＤＢ５２は、鍵情報毎に、車両が走行する道路を示す情報であるリンク情報（ＬｉｎｋＩＤ）と、その道路を走行した時間帯と、その道路を走行するうえでの運転者の精神的な負荷を定量評価した値とが関連づけて格納されている。ここで、車両が走行する道路は、ナビゲーションシステムに目的地の入力がある場合等において取得可能である。
【００２６】
本実施形態では、車両が走行する道路に応じた負荷の評価を、車両が交差点で右折または左折する手前の所定区間から右折または左折した後の所定区間に限って実行する。これは、車両が直進走行を継続する場合には、右折する場合や左折する場合と比較して、その道路を走行することに慣れているか否かによって運転者の精神的な負荷が大きく変わることはないと考えられることによる。このため、リンク情報は、上記手前の所定区間のリンク情報（ＬｉｎｋＩＤ（ＦＲＯＭ））と、上記後の所定区間のリンク情報（ＬｉｎｋＩＤ（ＴＯ））とする。図６に、リンク情報によって特定される区間を例示する。
【００２７】
走行履歴ＤＢ５２に、時間帯の情報を格納するのは、走行したことがある区間であっても、走行する時間帯が相違する場合には、精神的な負荷が大きくなりうることに鑑みたものである。すなわち、たとえば、普段、通勤に使用する道路の場合、平日の朝および夕方において車両の走行履歴が生じるものの、その道路を正午に走行することはない。ここで、例外的にその道路を正午に走行する場合には、通勤時にその道路を走行する場合とは相違する事態に遭遇する可能性が高くなるため、通勤時に走行する場合と比較して、精神的な負荷が大きくなると考えられる。なお、時間帯は、たとえば所定の時間幅（たとえば、１〜３時間）の間隔毎に設定すればよい。また、走行開始時間と走行終了時間との間の期間が複数の時間帯にまたがる場合、走行履歴ＤＢ５２に、複数の時間帯のそれぞれにおける走行履歴を格納すればよい。
【００２８】
周辺状態推定部Ｍ１６は、図４に示した関係情報を、リンク情報によって特定された区間に用いることで、その区間の特定の時間帯における精神的な負荷を定量評価する。すなわち、ある時間帯においてリンク情報によって特定される区間に関する前回運転の終了時からの経過時間が「２４」時間以内の場合の評価を「０」とし、５日連続運転する毎に、評価を「＋１」増加させる。ただし、評価の最大値を「３」とする。なお、通勤時間帯において平日毎日利用する区間については、その時間帯における評価は「＋１」となるものの、通勤時間帯以外の評価については、これとは相違する。このため、通勤時間帯において走行する区間を、例外的に通勤時間帯以外に走行した場合には、走行履歴ＤＢ５２には、同一の区間について互いに相違する時間帯のデータが格納されることとなる。なお、ある時間帯においてリンク情報によって特定される区間を走行したことがない場合には、走行履歴ＤＢ５２にはデータが格納されていないのであるが、前回の運転終了時から３０日以上経過しているのと同等とし、負荷が最も高いことを示す「−３」を付与する。
【００２９】
周辺状態推定部Ｍ１６は、走行履歴ＤＢ５２に格納する評価を更新する都度、この評価を周辺状態推定部Ｍ１６によって演算される負荷として、統合状態判定部Ｍ１８に出力する。なお、周辺状態推定部Ｍ１６は、これ以外にも、走行している道路の交通量や歩行者の有無に応じて運転者の負荷を演算し、演算結果を統合状態判定部Ｍ１８に適宜出力する。
【００３０】
こうして、車両状態推定部Ｍ１２や、ドライバ状態推定部Ｍ１４、周辺状態推定部Ｍ１６によって負荷が演算されると、統合状態判定部Ｍ１８では、これらに基づき、最終的な精神的な負荷を逐次算出し、最終的な負荷に基づき情報提供部３４を介して報知すべき情報を決定する。
【００３１】
次に、本実施形態の作用を説明する。
運転者が所持する携帯機によって車両の正当なユーザである旨の照合処理がなされると、ドライバ状態推定部Ｍ１４では、鍵情報に基づき、利用頻度ＤＢ４４内の情報のうち、鍵情報によって特定される情報を読み出す。そして、ドライバ状態推定部Ｍ１４では、図３に示した処理を実行することで、出発地点から目標地点まで走行するに際しての運転者の精神的な負荷のオフセット値を算出する。ここでオフセット値とは、統合状態判定部Ｍ１８によって算出される最終的な負荷が車両の走行に伴って逐次変動するものであるのに対し、その逐次変動する負荷を構成する一律の値のことである。なお、このオフセット値には、上述した運転マインドが反映される。これは、たとえば、利用頻度ＤＢ４４内の評価に対して、運転マインドがポジティブである場合には「＋１」を加算し、ネガティブである場合には「−１」を加算することで実現することができる。もっともこれに限らず、たとえば、運転マインドがポジティブである場合には上記評価の値を補正せず、ネガティブである場合には上記評価の値が負であることを条件に評価の値に正の補正係数（＞１）を乗算するようにしてもよい。
【００３２】
そして、統合状態判定部Ｍ１８では、車両の挙動に基づく運転者の負荷情報を車両状態推定部Ｍ１２から受け取り、この負荷情報に基づき上記オフセット値を増加補正する。また、車両が右折や左折をするに際して、その道路を走行した履歴があるか否かに応じた負荷情報を周辺状態推定部Ｍ１６から受け取り、上記オフセット値を更に増加補正する。
【００３３】
図７に、統合状態判定部Ｍ１８によって演算される負荷を例示する。図７は、図６に示した区間Ａを走行して交差点において右折することで区間Ｄへと進入する場合の負荷を例示する。なお、図７において横軸は、車両の走行経路を示し、縦軸は、統合状態判定部Ｍ１８によって演算される最終的な負荷を示す。図７において、曲線ｆ１は、区間Ａ，Ｄを走行するのが初めての場合の負荷の推移を示し、曲線ｆ２は、区間Ａ，Ｄの走行履歴を有する場合の負荷の推移を示す。
【００３４】
図７に示す例では、図６の区間Ａに進入する前には、運転者の精神的な負荷が、ドライバ状態推定部Ｍ１４から提供される負荷情報に基づくオフセット値Δとなっている。その後、区間Ａに進入することで、統合状態判定部Ｍ１８によって演算される負荷は上昇する。これは、上記オフセット値Δに、車両状態推定部Ｍ１２および周辺状態推定部Ｍ１６から出力される負荷情報が加わるためである。なお、図７においては、曲線ｆ１と曲線ｆ２との双方において、交差点の中心Ｐ付近で負荷が大きくなっているが、これは、車両状態推定部Ｍ１２から出力される負荷が大きくなるためである。すなわち、舵角センサ２２によって検出される舵角が大きくなることなどに起因して、中心Ｐ付近においては、車両状態推定部Ｍ１２によって演算される負荷が大きくなる。ちなみに、曲線ｆ１は、曲線ｆ２と比較して負荷が最大となる期間も長いが、これは、車両状態推定部Ｍ１２および周辺状態推定部Ｍ１６から出力される負荷情報を単に加算するのではなく、周辺状態推定部Ｍ１６から出力される負荷情報に鑑みて車両状態推定部Ｍ１２によって演算される負荷に重み付けをすることで実現することができる。
【００３５】
統合状態判定部Ｍ１８では、図７に示す負荷に応じて、情報提供部３４を介して提供する情報の内容やタイミングを可変設定する。ここでは、基本的には、負荷が大きいほど、報知する情報を制限することとなる。すなわち、負荷が大きい場合には、携帯電話の着信の有無、電子メールの受信の有無、ネットワーク上のニュースサイトから配信されるニュース等、車両の運転と直接関係しない情報については、その報知を制限する。ここでは、負荷が大きい期間における報知を禁止してもよい。ただし、たとえば音声による報知のみを禁止し、ディスプレイ上に小さなポップアップを表示することによる報知に限って許可するようにしてもよい。
【００３６】
ちなみに、負荷が大きい期間における報知を禁止する場合、負荷が小さくなることで報知がなされることとなる。ただし、たとえば、ニュースサイトの配信に関する報知を延期した結果、関連する最新のニュースが更に配信された場合には、延期していた報知についてはこれを報知することなく、負荷が小さくなることで最新のニュースが配信されたことのみを報知するようにしてもよい。この場合、負荷に応じて報知するタイミングを変更するのではなく、報知する内容を変更することとなる。
【００３７】
これに対し、走行を支援する情報については、負荷が大きい場合であっても、報知する。ただし、この場合であっても、負荷が大きい場合には小さい場合と比較してより簡潔な報知を行ったり、ストレスを低減する目的で音声報知の場合の周波数を変更したりしてもよい。
【００３８】
このように、報知の内容や報知のタイミングを可変とすることで、運転者が車両を運転するに際し、情報の報知が運転者の注意力のリソースを過度に消費する事態を好適に抑制することができる。
【００３９】
以上説明した本実施形態によれば、上記以外にも以下に記載する作用効果が得られるようになる。
（１）ドライバ状態推定部Ｍ１４が、運転終了日時からの経過時間が長いほど、今回の運転に加えられる精神的な負荷が大きくなるように負荷を演算した。これにより、しばらく運転をしていない場合の方がそうでない場合と比較して運転により多くの負荷がかかることを反映することができ、ひいては負荷を高精度に演算することができる。
【００４０】
（２）利用頻度ＤＢ４４において、鍵情報毎に、運転終了日時等を管理するようにした。これにより、同一の車両を複数の人が利用する場合であっても、各個人の運転履歴を考慮することができることから、負荷を高精度に演算することができる。
【００４１】
（３）統合状態判定部Ｍ１８が、ドライバ状態推定部Ｍ１４が運転終了日時からの経過時間に基づき演算する負荷を、最終的な負荷を演算するために用いるに際し、運転者のその日の精神状態を加味した。これにより、運転者に加わる負荷をより高精度の演算することができる。
【００４２】
（４）周辺状態推定部Ｍ１６が、走行する道路を運転者が過去に走行したか否かに応じて、また、過去の運転終了時からの経過時間に応じて、運転者の精神的な負荷を演算した。これにより、運転に慣れている道路と比較して慣れていない道路を走行する場合には運転により多くの負荷がかかることを反映することができ、ひいては負荷を高精度に演算することができる。
【００４３】
（５）周辺状態推定部Ｍ１６が、時間帯に応じて過去の走行履歴を参照した。これにより、現在の走行時間帯と過去の走行時間帯との差が規定値以下であることを条件に、過去の走行履歴を参照することができることから、走行したことがある場合であっても走行する時間帯が相違すれば走行条件に相違が生じることを反映して負荷を演算することができ、ひいては負荷を高精度に演算することができる。
【００４４】
（６）周辺状態推定部Ｍ１６が、交通量や歩行者の有無に応じて負荷を演算した。これにより、交通量や歩行者の有無に応じて運転にかかる負荷が相違することを反映して負荷を演算することができ、ひいては負荷を高精度に演算することができる。
【００４５】
（７）車両状態推定部Ｍ１２が、車両の挙動に基づき運転者に加わる負荷を演算した。これにより、単調な直進路を走行する場合と比較して、右左折する場合や、車線変更する場合、障害物を迂回する運転をする場合等の方が運転にかかる負荷が大きくなることを考慮することができ、ひいては負荷を高精度に演算することができる。
【００４６】
＜その他の実施形態＞
なお、上記各実施形態は、以下のように変更して実施してもよい。
・「運転履歴の記憶手法について」
利用頻度ＤＢ４４や走行履歴ＤＢ５２を利用するものに限らない。たとえば、車両の正当なユーザが、自己が正当なユーザであることを認証するために携帯する携帯機に記憶するものであってもよい。この場合、車両を利用するに際し、携帯機から車両に運転履歴に関する情報を送信すればよい。これにより、ドライバ状態推定部Ｍ１４や周辺状態推定部Ｍ１６は、図２および図５に示したデータに基づき評価処理を実行することができる。なお、携帯機としては、車両専用の装置に限らず、たとえば多機能電話機であってもよい。この場合、多機能電話機に専用のソフトウェア（アプリケーションプログラム）をインストールすることで、携帯機によって認証機能のみならず、運転履歴を管理する機能を実現すればよい。
【００４７】
・「ドライバ状態推定部について」
抑制機能変化要素の評価点数の設定としては、上記実施形態において例示したものに限らない。たとえば、前回の運転終了時から２４時間以上一週間以内については同一の評価点としてもよい。また、たとえば、前回の運転終了時から１０日以上１月以内については、同一の評価点としてもよい。さらに、前回の運転終了時から３０日以上経過した後であっても、経過日数が多くなることで更に評価を下げるようにしてもよい。さらに、たとえば、連続運転の日数については、３日連続する毎に評価をあげるようにしてもよい。ただし、いずれにせよ、評価点には上限値および下限値を設けることが望ましい。
【００４８】
最後の運転終了日の前日にも運転履歴がある場合に限って連続運転日数を考慮するものに限らない。たとえば、最後の運転終了時からの経過時間が１０日以上、３０日以内である場合において、その最後の運転日の前日に運転履歴がある（連続運転である）ときには、連続運転でないときと比較して評価を高めてもよい。
【００４９】
上記実施形態では、抑制機能変化要素の評価点数に対して運転マインドによって重み付け処理をすることで最終的な負荷を算出したが、これに限らない。さらに、運転マインドのみならず、ドライバモニタカメラ４０によって撮影される画像等に基づく負荷をも考慮することなく、評価点数自体をドライバ状態推定部Ｍ１４が算出する最終的な負荷としてもよい。
【００５０】
・「周辺状態推定部について」
ドライバ状態推定部が利用するデータ（抑制機能変化要素：図４）と同一のデータ（抑制機能変化要素）を用いて運転履歴に基づく負荷を評価するものに限らず、ドライバ状態推定部と周辺状態推定部とで利用するデータを互いに相違させてもよい。
【００５１】
具体的には、たとえば、前回の運転終了時からの経過時間が３０日以上経過している場合であっても、３０日以上前の期間における運転頻度が高い場合には、前回の運転終了時からの経過時間が１０日未満の場合と同等の評価としてもよい。
【００５２】
上記実施形態では、直進走行を継続する場合には、その道路を走行した履歴に基づく負荷の演算を行わなかったが行ってもよい。また、走行履歴を時間帯毎に別の履歴とすることは必須ではない。これを実行しなくても、何度も走行した道路と初めての道路とでは後者を走行する場合の方が負荷が大きくなると考えられることから、時間帯を無視した走行履歴を用いても走行履歴を反映することで走行履歴を反映しない場合と比較して負荷を高精度に演算することができる。
【００５３】
・「統合状態判定部について」
上記実施形態では、ドライバ状態推定部Ｍ１４が運転間隔に基づき演算する負荷を、最終的な負荷のオフセット値として利用したがこれに限らない。たとえば、ドライバ状態推定部Ｍ１４が運転間隔に基づき演算する負荷が大きい場合、車両状態推定部Ｍ１２によって演算される負荷を、所定の条件が成立する場合に限って増大させる補正をしてもよい。このように、最終的な負荷を、車両状態推定部Ｍ１２によって演算される負荷とドライバ状態推定部Ｍ１４によって演算される負荷との双方に基づき演算しつつも、それら双方の単純な四則演算によって求まるものとしないことで、運転者の負荷をより高精度に演算することも可能となる。
【００５４】
・「走行履歴に応じた負荷演算に際して考慮する他の要素について」
たとえば、利用する車両を更に考慮して負荷を演算してもよい。すなわち、たとえば、車両の正当なユーザが、自己が正当なユーザであることを認証するために携帯する携帯機に、運転履歴情報を記憶する構成において、その携帯機によって利用可能な車両が複数存在する場合には、いずれの車両を利用したかの履歴を更に考慮してもよい。具体的には、たとえば、図４に示した抑制機能変化要素を同一の車両を運転する場合のものとし、今回の運転に際して利用する車両と走行履歴のある車両とが相違する場合、抑制機能変化要素の評価点を図４に示したものに対して低下させてもよい。
【００５５】
・「負荷の演算部について」
車両に搭載される装置（状態推定ＥＣＵ６０）が負荷を演算するものに限らない。たとえば、車両の正当なユーザが、自己が正当なユーザであることを認証するために携帯する携帯機であってもよい。すなわち、携帯機に、たとえば、ドライバ状態推定部Ｍ１４および周辺状態推定部Ｍ１６の機能を持たせてもよい。この場合、統合状態判定部Ｍ１８は、携帯機から送信される負荷情報や、車両状態推定部Ｍ１２から送信される情報に基づき、情報の報知内容や報知タイミングを変更すればよい。またたとえば、携帯機にドライバ状態推定部Ｍ１４の機能を持たせるものの、周辺状態推定部Ｍ１６の機能を持たせないようにしてもよい。この場合、統合状態判定部Ｍ１８は、携帯機から送信される負荷情報や、車両状態推定部Ｍ１２および周辺状態推定部Ｍ１６から送信される情報に基づき、情報の報知内容や報知タイミングを変更すればよい。
【符号の説明】
【００５６】
Ｍ１０…車両情報取得部、Ｍ１２…車両状態推定部、Ｍ１４…ドライバ状態推定部、Ｍ１６…周辺状態推定部、Ｍ１８…統合状態判定部、１０…自車位置情報検出部、１２…周辺物体検出部、１４…ウィンカ、１６…道路交通情報通信システム、１８…ワイパ、２０…狭域通信部、２２…舵角センサ、２４…ヨーレートセンサ、２６…自動料金支払システム、２８…加速度センサ、３０…車速センサ、３２…拡張情報取得部、３４…情報提供部、４２…生体センサ、４６…周辺監視カメラ、４８…ミリ波レーダ、６０…状態推定ＥＣＵ。
【図１】
2016013753.tif 000003
【図２】
2016013753.tif 000004
【図３】
2016013753.tif 000005
【図４】
2016013753.tif 000006
【図５】
2016013753.tif 000007
【図６】
2016013753.tif 000008
【図７】
2016013753.tif 000009