以下、本発明の実施形態について図を用いて説明する。図1は、本発明に係る依存度推定装置としての機能を備える運転支援システム100の概略的な構成の一例を示す図である。運転支援システム100は車両に搭載されており、図1に示すように、運転支援ECU1、周辺監視センサ2、車両状態センサ3、ドライバ状態センサ4、スピーカ5、ディスプレイ6、入力装置7、近距離通信部8、及び走行制御ECU9を備える。なお、部材名称中のECUは、Electronic Control Unitの略であり、電子制御装置を意味する。
周辺監視センサ2、車両状態センサ3、ドライバ状態センサ4、スピーカ5、ディスプレイ6、入力装置7、近距離通信部8、及び走行制御ECU9のそれぞれは、車両内に構築された通信ネットワーク(以降、LAN:Local Area Network)を介して、運転支援ECU1と相互通信可能に接続されている。なお、LANには図示しないナビゲーション装置や、オーディオ装置、空調装置なども接続されている。以降では便宜上、運転支援システム100が搭載されている車両のことを自車両とも記載する。
運転支援ECU1は、運転席に着座している乗員(以降、ドライバ)の運転操作を支援する処理を実行するECUである。運転支援ECU1は、コンピュータとして構成されている。すなわち、運転支援ECU1は、演算処理を実行するCPU11、不揮発性のメモリであるROM12、揮発性のメモリであるRAM13、I/O14、及びこれらの構成を接続するバスラインなどを備える。CPU11は例えばマイクロプロセッサ等を用いて実現されればよい。ROM12は、より好ましい態様として書き換え可能な不揮発性のメモリとする。I/O14は、運転支援ECU1が外部装置(例えば周辺監視センサ2)とデータの入出力をするためのインターフェースである。I/O14は、ICやデジタル回路素子、アナログ回路素子などを用いて実現されればよい。
運転支援ECU1が備えるROM12には、通常のコンピュータを運転支援ECU1として機能させるためのプログラム(以降、運転支援プログラム)等が格納されている。なお、上述の運転支援プログラムは、ROM12を含む非遷移的実体的記録媒体(non- transitory tangible storage medium)に格納されていればよい。CPU11が運転支援プログラムを実行することは、運転支援プログラムに対応する方法が実行されることに相当する。運転支援ECU1は、CPU11が運転支援プログラムを実行することによって、後述する種々の機能を提供する。
周辺監視センサ2は、自車両の周辺に存在する物体についての情報を収集する装置である。周辺監視センサ2としては、例えば、車両外部の所定範囲を撮像する周辺監視カメラ、車両外部の所定範囲に探査波を送信するミリ波レーダ,LIDAR(Light Detection and Ranging/Laser Imaging Detection and Ranging)、ソナー等を採用することができる。ここでは一例として周辺監視センサ2は、車両前方を撮像するように搭載された周辺監視カメラとする。周辺監視センサ2としての周辺監視カメラは、撮像画像を運転支援ECU1へ逐次出力する。もちろん、周辺監視センサ2は、上述したセンサ以外の周知のものであってもよい。また、運転支援ECU1は、複数のセンサを備えていてもよい。
車両状態センサ3は、自車両の走行制御に関わる状態量を検出するセンサである。本実施形態における運転支援システム100は、車両状態センサ3として、ブレーキセンサ、アクセルセンサ、車速センサ、シフトポジションセンサ、及び舵角センサを備える。ブレーキセンサは、ブレーキペダルの位置、換言すれば、ドライバによってブレーキペダルが踏み込まれている量(以降、ブレーキ踏込量)を検出するセンサである。アクセルセンサは、アクセルペダルの位置、換言すれば、アクセルペダルがドライバによって踏み込まれている量(以降、アクセル踏込量)を検出するセンサである。車速センサは、自車両の走行速度を検出するセンサである。シフトポジションセンサは、シフトレバーの設定ポジションを検出するセンサである。舵角センサは、ハンドルの回転角(いわゆる操舵角)を検出するセンサである。
各センサは、検出対象とする物理状態量の現在の値(つまり検出結果)を示すデータを運転支援ECU1に逐次提供する。種々のセンサの検出結果は、任意の電子制御装置(ECU:Electronic Control Unit)等を介して運転支援ECU1に提供される構成となっていても良い。
なお、車両状態センサ3として運転支援ECU1が接続されるべきセンサの種類は適宜設計されればよく、上述した全てのセンサと接続されている必要はない。また、上述した以外のセンサ、例えばヨーレートセンサと接続されていても良い。ヨーレートセンサは自車両の垂直軸周りの回転角速度(すなわち、ヨーレート)を検出するセンサである。
また、運転支援ECU1は、上述した操作量センサの検出結果以外にも、ドライバの運転操作の内容を示す情報として、警音器(いわゆるクラクション又はホーン)の動作状態を示す信号や、方向指示器の動作状態を示す信号を取得可能に構成されている。なお、ブレーキセンサや、アクセルセンサ、舵角センサ、シフトポジションセンサ等は、ドライバの運転操作の内容を検出するセンサとしても機能する。ドライバの運転操作の内容を検出するセンサのことを以降では便宜上、操作量センサとも記載する。
ドライバ状態センサ4は、例えばドライバの顔の向きや、視線の方向、瞼の開度、体の向き、ハンドルの把持状態といった、ドライバの状態を検出するセンサである。ドライバ状態センサ4としては、例えば、上半身カメラ、顔カメラ、マイク、ハンドル把持センサ、背圧センサ、座圧センサ等を採用することができる。上半身カメラは、ドライバの上半身を撮像するように設置されたカメラである。上半身カメラは、例えば、ドライバの上半身を撮像するようにルームミラー付近に設置されれば良い。もちろん、上半身カメラは、ステアリングコラムカバーや、インストゥルメントパネルの運転席に対向する部分などに設置されていても良い。上半身カメラは撮像画像を運転支援ECU1に逐次出力する。
顔カメラは、ドライバの顔部を撮影する装置である。顔カメラは、例えば近赤外光源、近赤外カメラ、及びそれらを制御する制御ユニットを用いて実現される。顔カメラは、近赤外カメラの撮像画像に対して周知の画像認識処理を施すことで、運転席における乗員の頭部姿勢や、ドライバの顔の向き、視線方向、瞼の開き度合い等を逐次検出する。なお、顔カメラは、運転席に着座している乗員の顔領域を撮影するように、例えばステアリングコラムカバーや、インストゥルメントパネルの運転席に対向する部分等、適宜設計される位置に配置されていればよい。顔カメラは、撮影画像から特定したドライバの頭部姿勢や、顔の向き、視線方向、瞼の開き度合い等を示す情報を、運転支援ECU1へ逐次出力する。
マイクは、自車両の車室内に設けられた集音装置である。マイクはドライバ等が発話した音声を集音し、電気的な音声信号に変換して運転支援ECU1へ出力する。マイクは、ドライバの音声を集音しやすいように運転席付近に設けることが好ましい。
ハンドル把持センサは、ハンドルに設けられた圧力センサであって、ドライバがハンドルを握る圧力を検出する。ハンドル把持センサの出力信号は、ドライバが両手でハンドルを把持しているか否かを示す信号としても機能する。背圧センサは、運転席の背もたれ部分に配置された圧力センサシートであって、運転席の背もたれ部に作用している圧力の分布を検出する。座圧センサは、運転席の着座面に配置された圧力センサシートであって、運転席の着座面に作用している圧力の分布を検出する。
スピーカ5は、運転支援ECU1から入力された信号に基づいて音声や警報音を出力する。なお、スピーカ5は、運転支援ECU1だけでなく、ナビゲーション装置やオーディオ装置等から入力された信号に基づいても音を出力する。
ディスプレイ6は、運転支援ECU1から入力された画像を表示するデバイスである。本実施形態では一例としてディスプレイ6は、インストゥルメントパネルの車幅方向中央部(以降、中央領域)の最上部に設けられたディスプレイ(いわゆるセンターディスプレイ)とする。ディスプレイ6は、フルカラー表示が可能なものであり、液晶ディスプレイ、有機ELディスプレイ、プラズマディスプレイ等を用いて実現することができる。
なお、他の態様としてディスプレイ6は、フロントガラスの運転席前方の一部分に虚像を映し出すヘッドアップディスプレイであってもよい。また、ディスプレイ6は、インストゥルメントパネルにおいて運転席の正面に位置する領域に配置されたディスプレイ(いわゆるメータディスプレイ)であってもよい。
入力装置7は、ナビゲーション装置や、オーディオ装置、空調装置等といった、自車両に搭載されている種々の電子機器(以降、車載機器)に対するドライバの指示操作を受け付けるためのデバイスである。本実施形態では一例として入力装置7は、ディスプレイ6に積層されたタッチパネルとする。入力装置7としてのタッチパネルは、ユーザによってタッチされている位置を示すタッチ位置信号を操作信号として所定の車載機器及び運転支援ECU1に逐次出力する。すなわち、入力装置7は、ドライバが入力装置7に対して実行した操作に対応する制御信号を、ドライバの操作内容に応じた車載機器及び運転支援ECU1に出力する。
なお、本実施形態では入力装置7としてタッチパネルを採用する構成とするが、これに限らない。入力装置7は、ハンドル等に設けられたメカニカルなスイッチ(つまり、ステアリングスイッチ)であってもよいし、周知の音声認識技術を用いて実現される音声入力装置であってもよい。また、センターコンソールに配置されたハプティックデバイスであってもよい。その他、マウス、キーボードなどであっても良い。運転支援システム100は上述した複数種類のデバイスを入力装置7として備えていても良い。
近距離通信部8は、ドライバが携帯する情報処理端末である携帯端末と、所定の近距離無線通信規格に準拠した無線通信(以降、近距離通信)を実施するための通信モジュールである。ここで採用される近距離無線通信規格は、通信可能な範囲が最大でも数十メートル程度となる無線通信の規格である。近距離通信の規格としては、例えばBluetooth(登録商標)や、Wi−Fi(登録商標)等を採用することができる。
携帯端末は、前述の近距離通信を実施する機能(以降、近距離通信機能)を備える情報処理端末であればよい。例えば、スマートフォンや、携帯電話機、タブレット端末、ウェアラブルデバイス、携帯用音楽プレーヤ、携帯用ゲーム機等を携帯端末として採用することができる。
携帯端末は、近距離通信機能がオンとなっている場合、自分自身に割り当てられた固有の端末番号(以降、端末IDとする)を含むアドバタイズ信号を定期送信する。なお、他の態様として、携帯端末は運転支援システム100からの要求に基づいてアドバタイズ信号を送信する態様となっていてもよい。
近距離通信部8は、携帯端末から送信されるアドバタイズ信号を受信することで、車室内に携帯端末が存在することを認識し、携帯端末との通信接続を確立する。なお、近距離通信部8には、ドライバとしてのユーザによって予め、近距離通信部8が通信接続すべき携帯端末の情報(例えば端末ID)が登録されているものとする。
携帯端末は、近距離通信部8との通信接続が確立している場合、車載機器を操作するためのデバイス(つまり入力装置7)として機能する。また、携帯端末は、近距離通信部8との通信接続が確立している場合、ディスプレイに表示する画像を提供する画像信号源としても機能しうる。
走行制御ECU9は、運転支援ECU1からの指示に基づいて所定の車載アクチュエータを駆動させることにより、操舵、加速、制動等の車両制御を実行するECUである。走行制御ECU9は運転支援ECU1に統合されていてもよい。
<運転支援ECU1が備える機能について>
運転支援ECU1は、CPU11が上述の運転支援プログラムを実行することによって、図2に示す種々の機能ブロックに対応する機能を提供する。すなわち、運転支援ECU1は機能ブロックとして、周辺物情報取得部F1、リスク検出部F2、支援処理部F3、挙動監視部F4、依存度評価部F5、及び支援態様調整部F6を備える。
なお、運転支援ECU1が備える機能ブロックの一部又は全部は、一つあるいは複数のIC等を用いて(換言すればハードウェアとして)実現されていてもよい。また、運転支援ECU1が備える機能ブロックの一部又は全部は、CPU11によるソフトウェアの実行とハードウェア部材の組み合わせによって実現されていてもよい。
また、運転支援ECU1は、ドライバ状態記憶部M1と、支援パラメータ記憶部M2とを備える。ドライバ状態記憶部M1は、後述する挙動監視部F4によって逐次特定されるドライバの状態を示すデータを保存するための記憶領域である。支援パラメータ記憶部M2は、支援処理部F3が運転支援処理を実施する際の制御パラメータ(以降、支援パラメータ)を保持する記憶領域である。支援パラメータには、情報を提示するタイミング等を規定する報知態様パラメータが含まれる。ドライバ状態記憶部M1及び支援パラメータ記憶部M2は、RAM13等の書き換え可能な記憶媒体を用いて実現されれば良い。
周辺物情報取得部F1は、周辺監視センサ2の出力データに基づいて、自車両の周辺に存在する所定の対象物についての情報を取得する構成である。本実施形態の周辺物情報取得部F1は、周辺監視センサ2の撮像画像に対して画像認識処理を実施し、所定の対象物を検出するとともに、検出した対象物の自車両に対する相対位置や、相対的な移動方向、移動速度等を特定する。
ここでの対象物とは、例えば、歩行者、人間以外の動物、他車両、道路沿いに設置される構造物などである。他車両には自転車や原動機付き自転車、オートバイも含まれる。道路沿いに設置される構造物とは、例えば、ガードレール、縁石、樹木、電柱、道路標識、信号機などである。また、本実施形態ではより好ましい態様として、走行区画線等の路面標示や、路上の落下物なども対象物として登録されているものとする。
周辺物情報取得部F1は、自車両の周辺に存在する対象物毎に、相対位置等の情報を取得する。以降では便宜上、自車両の周辺に存在する対象物毎の種別や相対位置、移動方向、移動速度を示す情報を周辺物情報と称する。なお、周辺監視カメラの撮像画像から対象物についての情報を抽出する機能は、周辺監視カメラ自体に備えられていても良い。その場合、周辺監視カメラから提供されるデータをそのまま周辺物情報として利用することができる。
また、周辺物情報取得部F1は、画像認識技術によって道路標識,路面標示の規制内容を認識することで、自車両が走行している道路の制限速度を逐次認識する。なお、本実施形態では周辺監視センサ2の検出結果に基づいて、自車両周辺の構造物や、制限速度などの情報を取得するものとするが、これに限らない。自車両周辺の構造物や、制限速度などの情報については、細かい地図要素の情報を収録した詳細地図データから取得しても良い。
リスク検出部F2は、周辺物情報取得部F1が取得した周辺物情報や、車両状態センサ3の検出結果に基づいて、自車両の走行状態が所定のリスク状態となっていることを検出する。リスク状態とは、例えば、他の対象物との衝突が予見される状態である。
具体的には、リスク検出部F2は、周辺物情報取得部F1が取得した周辺物情報に基づいて、自車両と衝突する可能性がある対象物(以降、リスク対象物)が存在するか否かを判定する。例えばリスク検出部F2は、対象物毎に、自車両と衝突するまでの残り時間である衝突残余時間(以降、TTC:Time-To-Collision)を逐次算出し、TTCが所定の閾値以下となっている物体をリスク対象物と判定する。或る対象物についてのTTCは、当該対象物の相対位置、相対速度、及び相対的な移動方向に基づいて算出されれば良い。TTCの算出アルゴリズムは周知のものを援用することができる。
なお、走行区画線、停止線等の路面標示といった、自車両の走行を妨げない物体については、自車両と衝突する可能性がない物体として取り扱えば良い。また、本実施形態では一例としてTTCの概念を用いてリスク対象物を検出するように構成されているが、リスク対象物の検出方法はこれに限らない。例えば、対象物との距離に基づいて判定しても良い。
或る対象物をリスク対象物と判定することは、自車両周辺に存在するリスク対象物を検出することに相当する。また、リスク対象物が存在するということは、自車両の走行状態が所定のリスク状態となっていることを意味する。
支援処理部F3は、リスク検出部F2によって検出されたリスク状態に応じた運転支援を実施する構成である。支援処理部F3は、より細かい構成要素(換言すればサブ機能)として、報知処理部F31と車両制御部F32とを備える。
報知処理部F31は、リスク検出部F2によって検出されているリスク状態を、警報音等を用いてドライバに報知する処理(以降、注意喚起処理)を実行する構成である。報知処理部F31は、リスク検出部F2によってリスク対象物の存在が検出されている場合、当該リスク対象物が存在することをドライバに報知する。本実施形態では一例として報知処理部F31は、リスク対象物の存在が検出されている場合には、リスク対象物の存在をドライバに知らせる警報音をスピーカ5から出力する。
なお、警報音の代わりに所定の音声メッセージを出力することによってリスク対象物の存在をドライバに報知してもよい。また、報知処理部F31は、注意喚起処理として、リスク対象物の存在をドライバに知らせる画像をディスプレイ6に表示してもよい。その他、バイブレータを所定の振動パターンで振動させることによってユーザにリスク対象物の存在することを報知してもよい。さらには、少なくとも1つ発光素子(例えば発光ダイオード)を用いて実現されるインジケータを、所定の発光パターンで発光させることによって上記情報をドライバに通知してもよい。なお、発光パターンは、光の色や、点滅の周期等の組み合わせによって構成される。
また、本実施形態ではより好ましい態様として報知処理部F31は、単にリスク対象物が存在することだけでなく、リスク対象物が存在する方向(以降、リスク存在方向)についてもドライバに報知する。例えば警報音を用いて注意を促す場合には、周知の立体音響技術を用いてリスク存在方向に応じた位置に仮想音像を定位させる。そのような構成によれば、ドライバは仮想音像が定位している方向にリスク対象物が存在することを直感的に認識できる。また、音声メッセージや画像を用いて注意を促す場合には、リスク存在方向について言及した情報を出力すれば良い。
なお、リスク対象物となりうる物体は、車両前方に存在する対象物に限らない。自車両が後退している場合には、自車両後方に存在する物体もリスク対象物となりうる。すなわち、自車両の進行方向に存在する物体はリスク対象物となりうる。さらに、ドライバが車線変更をしようとしている場合には、変更先の車線において、自車両よりも後方を走行している他車両もリスク対象物となりうる。交差点付近においては、自車両が走行している道路と交わる道路を走行している他車両や歩行者も、リスク対象物となりうる。このように斜め前方や、後方、斜め後方もリスク存在方向となりうる。
なお、リスク対象物が存在することを示す情報には、リスク対象物との衝突を回避するためにドライバが実施すべき運転操作を示す情報も含まれる。報知処理部F31が報知する情報は、自車両に生じているリスク状態に対して注意を促す情報(以降、注意喚起情報)であればよい。報知処理部F31によって注意喚起情報が報知されることで、ドライバは自車両に差し迫っているリスクを認識することができる。注意喚起情報が請求項に記載の支援情報に相当する。
車両制御部F32は、リスク検出部F2が算出しているTTCに基づいて、リスク対象物との衝突を回避、又は、衝突時の衝撃を軽減するための車両制御を実行する条件(以降、制御介入条件)が充足されたか否かを逐次判定する。車両制御部F32は、制御介入条件が充足された場合、リスク対象物との衝突を回避、又は、衝突時の衝撃を軽減するための車両制御を、走行制御ECU9と協働して実行する。
例えば車両制御部F32は、車両前方に存在する対象物(例えば先行車両)とのTTCが所定の作動閾値(例えば1.5秒)以下となった場合、走行制御ECU9に対して自車両を停止又は所定の減速度で減速させるように指示を出す。走行制御ECU9は、運転支援ECU1からの指示に基づいて、ブレーキアクチュエータを作動させて自車両を減速させる。なお、上記の例では、TTCが所定の作動閾値以下となった状態が、制御介入条件が充足された状態に相当する。
挙動監視部F4は、ドライバ状態センサ4や入力装置7等から信号に基づいて、ドライバの状態を逐次(例えば200ミリ秒毎に)特定する。例えば挙動監視部F4は、入力装置7から操作信号が出力されている場合、ドライバはナビゲーション装置等の車載機器を操作している状態であると判定する。挙動監視部F4が請求項に記載のドライバ状態特定部に相当する。
なお、他の態様として挙動監視部F4は、顔カメラによってドライバの顔及び目線がディスプレイ6が設置されている方向に向いていることが検出されている場合に車載機器を操作していると判定してもよい。また、ドライバが車載機器を操作しているか否かは上半身カメラの撮像画像から判定しても良い。さらに、挙動監視部F4は、近距離通信部8が携帯端末から送信された車載機器に対する制御信号を受信している場合、ドライバは携帯端末を介してナビゲーション装置等の車載機器を操作している状態であると判定してもよい。
また、挙動監視部F4は、ドライバの顔が足元や助手席方向など車両前方以外の方向に向いている場合、ドライバは車両前方を見ていない状態と判定する。ドライバの視線方向は、顔カメラによって特定されればよい。また、ドライバの顔の向きは、上半身カメラの撮像画像から特定されても良い。ドライバは車両前方を見ていない状態は、脇見をしている状態(以降、脇見状態)に相当する。なお、本実施形態ではより好ましい態様として、ドライバの視線がルームミラーやサイドミラーに向けられている場合には、脇見状態とは判定しないものとする。また、ドライバの顔が車両斜め後方に向けられている場合も脇見状態とは判定しない。ドライバの顔が車両前方に向けられている場合には、ドライバは車両前方を見ていると判定すればよい。
さらに、挙動監視部F4は、マイクがドライバの発話音声を取得している場合には、ドライバが同乗者と会話している/歌を歌っていると判定する。マイクがドライバの発話音声を取得していない場合には、ドライバが同乗者と会話したり歌を歌ったりはしていないと判定すればよい。なお、予めドライバの声と他者の声とを識別するためのデータ(例えばドライバの音声データ)が予め登録されていることが好ましい。そのような態様によればドライバの声と、他の乗員との声の混同を避けることができる。
また、挙動監視部F4は、上半身カメラの撮像画像に基づいて、ドライバが片手運転をしているか否かを判定する。片手運転をしている状態とは、ハンドルを片手で把持している状態である。なお、片手運転しているか否かは、ハンドル把持センサの検出結果に基づいて判定しても良い。
挙動監視部F4は、上半身カメラの撮像画像に基づいて、ドライバの姿勢が所定の不適切姿勢となっているか否かを判断しても良い。不適切姿勢とは、運転操作に不適切な姿勢であって、例えば肘掛けや背もたれにも寄りかかった姿勢である。なお、運転操作に適した姿勢(以降、適正姿勢)とは、背筋を伸ばした姿勢である。上述の片手運転をしている状態も不適切運転姿勢に該当する。
ドライバの姿勢が不適切姿勢であるか適正姿勢であるかは、背圧センサ及び座圧センサの検出結果に基づいて判定されても良い。例えば、背圧センサによって背もたれに印加されている圧力が所定の閾値以下であり、座圧センサによって検出されている圧力分布の中心が、着座面の車幅方向中央付近に位置している場合には、適正姿勢と判定する。なお、背圧センサによって背もたれに印加されている圧力が所定の閾値以上であったり、座圧センサによって検出されている圧力分布の中心が着座面の右側又は左側に偏ったりしている場合には不適切姿勢と判定すればよい。
また、挙動監視部F4は、ブレーキセンサ等の操作量センサの検出値に基づいて、ドライバが実施している運転操作の内容を特定する処理を実施する。例えば挙動監視部F4は、操舵角センサの検出値からドライバの操舵方向や、操舵量、操舵角速度等を特定する。また、挙動監視部F4は、ブレーキセンサの検出値やアクセルセンサの検出値に基づいて減速操作を実施しているかを特定する。ドライバが警音器を吹鳴させる操作(以降、吹鳴操作)を実施した場合には、警音器の動作状態を示す信号に基づいて警音器を吹鳴操作が実施されたことも検出する。
挙動監視部F4は、上述したように、適切な運転姿勢であるか否か、車載機器等を操作しているか否か、視線方向などといった、ドライバの状態を逐次特定し、その特定結果を示すデータをドライバ状態記憶部M1に逐次保存していく。ドライバ状態記憶部M1には直近一定時間以内のドライバの状態を示すデータが時系列順に並んで保存される。
また、挙動監視部F4は、サブ機能として、適応操作判定部F41及び準備行動判定部F42を備える。適応操作判定部F41は、報知処理部F31が注意喚起処理を実行した場合に、報知処理部F31が報知した情報に応じた運転操作(以降、適応操作)をドライバが実施したか否かを判定する構成である。報知処理部F31によって報知された情報に応じた運転操作とは、リスク対象物との衝突を回避、又は、衝突時の衝撃を緩和するための運転操作である。例えば、先行車両との衝突の可能性が報知されている場合の適応操作とは、ブレーキペダルの踏込等に代表される減速操作である。なお、アクセルペダルから足を離す行動を、適応操作として設定しても良い。また、ブレーキペダルに足を載せることを適応操作として設定しても良い。
さらに、リスク対象物が存在しない方向への操舵を適応操作に含めてもよい。その場合には、操舵の結果として、リスク検出部F2がリスク対象物との衝突の可能性が無くなったと判定した場合に、適応操作が実行されたと判定すればよい。
準備行動判定部F42は、報知処理部F31が注意喚起処理を実行してからドライバが適応操作を実施するまでの間に、当該適応操作を実施するための準備行動をドライバが実施したか否かを判定する構成である。
適応操作を実施するための準備行動とは、例えば、リスク存在方向の視認、車載機器の操作の中断、携帯端末の操作の中断、同乗者との会話の中断、運転姿勢の是正などである。例えば注意喚起処理実行前ドライバが脇見をしている状態において、視線/顔をリスク存在方向に向けることなく適応操作が実施された場合には、準備行動が実施されなかったと判断する。リスク存在方向を視認したか否かは前述の通り顔カメラの検出結果や、上半身カメラの撮像画像から特定されれば良い。図3に示す視認判定部F421はドライバがリスク存在方向を視認したか否かを判定する機能ブロックを表している。
なお、リスク存在方向が斜め後方を含む車両後方である場合、バックミラーやサイドミラーを見る挙動も、リスク存在方向を視認する行動に含まれることが好ましい。さらに、周辺監視カメラの撮像画像がディスプレイ6に表示される構成においては、ディスプレイ6の表示画面を見る挙動も視認挙動に含まれることが好ましい。
また、注意喚起処理実行前、ドライバが車載機器を操作している状態において、車載機器の操作を継続したまま適応操作が実施された場合には、準備行動が実施されなかったと判断すればよい。さらに、注意喚起処理実行前においてドライバが携帯端末を操作している状態において、携帯端末の操作を継続したまま適応操作が実施された場合には、準備行動が実施されなかったと判断する。
その他、注意喚起処理実行前、ドライバが同乗者と会話している状況において、同乗者との会話を継続したまま適応操作が実施された場合には、準備行動が実施されなかったと判断してもよい。また、注意喚起処理実行前、片手運転等の不適切な姿勢を取っている状態において、不適切な姿勢を維持したまま適応操作が実施された場合に、準備行動が実施されなかったと判断してもよい。
入力装置7や携帯端末を介して車載機器を操作することや、脇見をすること、同乗者との会話に夢中になること、不適切な姿勢をとることなどは、適正な姿勢で車両前方を見ることに比べて、相対的に不安全な振る舞いといえる。本実施形態では一例として、準備行動判定部F42は、注意喚起処理実行前においてドライバが取っていた不安全な振る舞いの全部が解消された場合に準備行動が行われたと判定するが、これに限らない。注意喚起処理実行前においてドライバが取っていた不安全な振る舞いの一部が解消された場合に準備行動が行われたと判定しても良い。また、そもそも注意喚起処理実行前において上述した不安全な振る舞いが行われていなかった場合には、準備行動が実施されたと判定すればよい。
便宜上、車載機器の操作の中断、携帯端末の操作の中断、同乗者との会話の中断などといった、リスク存在方向の視認以外の準備行動をサブ準備行動と称する。図3に示すサブ準備行動判定部F422は、ドライバがサブ準備行動を実施したか否かを判定する機能ブロックである。サブ準備行動判定部F422が請求項に記載のサブ準備行動検出部に相当する。なお、準備行動判定部F42は必ずしも上述した全ての種類の準備行動を判定する必要はない。例えば準備行動判定部F42は視認判定部F421とサブ準備行動判定部F422の何れか一方のみを備える構成であってもよい。準備行動判定部F42が判定する準備行動の種類は適宜設計されれば良い。換言すれば、準備行動とするドライバの挙動は設計者によって適宜定義されれば良い。
依存度評価部F5は、報知処理部F31の出力に対する適応操作判定部F41の判定結果及び準備行動判定部F42の判定結果(つまりドライバの挙動)に基づいて、ドライバの運転支援システム100への依存度を設定する。ここでは一例として、依存度の高さを、レベル1からレベル4までの4段階で表現されるものとする。レベル1は依存度が最も低い状態を表し、レベル4は依存度が最も高い状態を表す。依存度の算出アルゴリズムの一例については別途後述する。
支援態様調整部F6は、依存度評価部F5が算出した依存度に基づいて、報知態様パラメータの値を調整する。報知態様パラメータとは、報知処理部F31がリスク対象物を報知する際の態様を構成する各種パラメータである。報知態様パラメータには、例えば注意喚起情報を出力するタイミング(以降、報知タイミング)と、ドライバに与える刺激の強さ(以降、刺激強度)とが含まれる。
なお、本実施形態のように注意喚起が警報音によって実現される場合の刺激強度を構成する要素としては、音量、周波数、吹鳴間隔などがある。音量が大きいほど、周波数が高いほど、吹鳴間隔が短いほど、刺激強度は高い。なお、他の態様として報知媒体が画像である場合の刺激強度を構成する要素としては、画像の表示色、点滅間隔などがある。表示画像の色合いが赤色に近いほど、表示画像の点滅間隔が短いほど、刺激強度は高くなる。また、報知媒体が光である場合、発光色が赤色に近いほど、光の明滅間隔が短いほど、刺激強度は高くなる。
本実施形態の支援態様調整部F6は、図4に示すように、依存度が高いほど報知タイミングを遅くするとともに、刺激強度を高くする。具体的には、依存度がレベル1の場合には所定の周波数で警報音を出力する。そして、依存度が高いほど、周波数を高くする。
また、依存度がレベル1の場合には、ドライバの依存度が小さい場合を想定した所定のタイミング(以降、デフォルトタイミング)で注意喚起情報を出力する。デフォルトタイミングは、例えばTTCが3秒となるタイミングとすればよい。そして、依存度が高いほど、注意喚起情報の報知タイミングを遅くする。例えば、レベル2のときにはTTC=2.5秒となった時、レベル3のときにはTTC=2.0秒となった時、レベル4のときにはTTC=1.8秒となった時とすればよい。
依存度が高いほど報知タイミングを遅くすることで、車両走行中にドライバが危機感を覚える機会を増やすことができる。その結果、ドライバが運転支援システム100を過信することを抑制することができる。支援態様調整部F6が請求項に記載の報知態様調整部に相当する。
<依存度推定関連処理>
次に図5に示すフローチャートを用いて、運転支援ECU1が実施する依存度推定関連処理について説明する。依存度推定関連処理は、運転支援ECU1が運転支援システム100に対するドライバの依存度を推定するとともに、その推定結果に基づいて報知態様パラメータを調整する処理である。この図5に示すフローチャート(換言すれば依存度推定関連処理)は、リスク検出部F2によってリスク状態が検出された場合に開始されればよい。
まずステップS1では依存度評価部F5が、以降の処理で用いるフラグである準備行動フラグと適応操作フラグを初期化(ここではオフ状態)に設定してステップS2に移る。準備行動フラグは、ドライバが準備行動を実施したか否かを表すフラグである。準備行動判定部F42は、ドライバが準備行動を実施したと判定した場合には準備行動フラグをオンに設定する。その他の場合には準備行動フラグはオフに設定されている。適応操作フラグは、ドライバが適応操作を実施したか否かを表すフラグである。適応操作判定部F41は、ドライバが適応操作を実施したと判定した場合に適応操作フラグをオンに設定する。その他の場合には適応操作フラグはオフに設定されている。
ステップS2では報知処理部F31が、リスク検出部F2によって検出されているリスク状態に応じた注意喚起処理を実施してステップS3に移る。例えば、自車両が先行車両と衝突しそうな場合には、先行車両の存在をドライバに気づかせるための注意喚起情報を出力する。注意喚起処理自体は、現在設定されている依存度に応じた報知態様パラメータに基づいて実行される。具体的には、先行車両とのTTCが報知タイミングとして設定されている時間となったタイミングで、所定の周波数の警報音を出力する。
ステップS3では準備行動判定部F42が、ドライバが準備行動を実施したか否かを判定する。準備行動を実施したか否かの判定アルゴリズムは前述の通りである。なお、後続するステップS4が実行されたことに由来して、ステップS3に遷移した時点で既に準備行動フラグがオンとなっている場合にはステップS3は実行せずにステップS5に移れば良い。つまり、準備行動フラグがオンに設定されている場合ステップS3は省略可能である。
準備行動が行われたと判定した場合にはステップS3が肯定判定されてステップS4に移る。一方、準備行動の実施をまだ検出していない場合にはステップS3が否定判定されてステップS5に移る。ステップS4では準備行動判定部F42が準備行動フラグをオンに設定してステップS5に移る。
ステップS5では適応操作判定部F41が、適応操作を実施したか否かを判定する。適応操作を実施したか否かの判定アルゴリズムは前述の通りである。適応操作が行われたと判定した場合にはステップS5が肯定判定されてステップS6に移る。一方、適応操作の実施をまだ検出していない場合にはステップS5が否定判定されてステップS3に移る。ステップS6では適応操作判定部F41が適応操作フラグをオンに設定してステップS7に移る。
ステップS7では車両制御部F32が、リスク検出部F2の検出結果に基づき、制御介入条件が充足されたか否かを判定する。制御介入条件が充足されている場合には、ステップS8に移り、現在の状況に応じた車両制御を実行するように走行制御ECU9に指示信号を出力する。例えば、先行車両とのTTCが1.5秒以内となっている場合には自車両を所定の減速度で減速させる。また、上記の減速制御と並行して、自車両がリスク対象物を避ける方向に移動するように操舵する車両制御(以降、操舵制御)を行ってもよい。ステップS7の時点において未だ制御介入条件が充足されていない場合にはステップS7が否定判定されてステップS3に移る。なお、車両制御条件が充足される場合とは、ドライバが注意喚起処理で報知された情報に応じた適切な運転操作(つまり適応操作)を実行しなかった場合に相当する。
ステップS9では依存度評価部F5が、以上の一連の処理の結果、すなわち注意喚起処理に対するドライバの挙動に基づいて、依存度を設定する。本実施形態では一例として図6に示すように、準備行動フラグの設定状態(すなわちオン/オフ)及び適応操作フラグのオン/オフの組み合わせに基づいて依存度を決定する。
具体的には、適応操作フラグがオンに設定されており且つ準備行動フラグがオンに設定されている場合には依存度をレベル1に設定する。適応操作フラグがオンに設定されており且つ準備行動フラグがオフに設定されている場合には依存度をレベル2に設定する。適応操作フラグがオフに設定されており且つ準備行動フラグがオンに設定されている場合には依存度をレベル3に設定する。適応操作フラグがオフに設定されており且つ準備行動フラグがオフに設定されている場合には依存度をレベル4に設定する。ステップS9での処理が完了するとS10に移る。
ステップS10では支援態様調整部F6が、ステップS9にて依存度評価部F5が新たに算出した依存度に基づいて、報知態様パラメータの値を調整し、支援パラメータ記憶部M2に保存する。これにより、次回の注意喚起処理は、今回のフローによって決定された報知態様に基づいて実行される。
<実施形態のまとめ>
以上の構成では、適応操作を実施したか否かだけでなく、準備行動を行ったか否かに基づいても依存度を決定する。ここでの準備行動とは、サブタスクの中断や、姿勢の是正、リスク方向の目視などが該当する。サブタスクとは、車載機器の操作や携帯端末の操作といった運転操作以外の作業を指す。
このような構成によれば、不安全な状態を維持したまま回避行動を実施した場合と、周辺確認などの準備動作を実施した後に回避行動を実施した場合と、を切り分けることができる。故に、運転支援システム100に対するドライバの依存度をより適切に判定することができる。
なお、以上では支援情報としての注意喚起情報に対するドライバの挙動に基づいて、依存度を設定する態様を開示したが、支援情報は注意喚起情報に限らない。自車両が自動運転機能を備えている場合、支援情報は、運転席乗員から車両に運転操作の権限を移譲できる状態となったことを示す自動運転可能情報であってもよい。また、運転席乗員に対して運転操作の権限を受け取るように依頼する交代依頼情報であってもよい。
以上、本発明の実施形態を説明したが、本発明は上述の実施形態に限定されるものではなく、以降で述べる種々の変形例も本発明の技術的範囲に含まれ、さらに、下記以外にも要旨を逸脱しない範囲内で種々変更して実施することができる。
なお、前述の実施形態で述べた部材と同一の機能を有する部材については、同一の符号を付し、その説明を省略する。また、構成の一部のみに言及している場合、他の部分については先に説明した実施形態の構成を適用することができる。
[変形例1]
上述した実施形態では依存度のみに基づいて報知態様パラメータを調整する構成を開示したが、これに限らない。依存度に加えて、ドライバの心拍数や呼吸間隔といった生体情報も用いて、報知態様パラメータを調整してもよい。生体情報には、ドライバの行動として反映されない情報を含まれるため、上記の構成によれば、報知態様の調整による依存度の適正化をより効果的に実施することができるようになる。以下、ドライバの生体情報を用いて報知態様を調整する構成を変形例1として以下に述べる。
変形例1の運転支援システム100は、図7に示すように、ドライバ状態センサ4としてドライバの生体情報を検出する生体情報センサ41を備える。ここでは一例として、生体情報センサ41は、心拍数を計測する心拍数センサとする。生体情報センサ41の検出結果は、逐次(例えば100ミリ秒毎に)運転支援ECU1に提供される。
なお、生体情報センサ41の種類は適宜設計されればよい。例えば生体情報センサ41は、血圧、心電位、脈波、発汗量、体温、呼吸のリズムや、呼吸の深さなどを検出対象とするセンサであっても良い。
変形例1における挙動監視部F4は、ドライバの心拍数を示すデータを生体情報センサ41から逐次取得し、ドライバ状態記憶部M1に逐次保存していく。ドライバ状態記憶部M1には、直近一定時間以内のドライバの心拍数を示すデータが時系列順に保存される。
変形例1における運転支援ECU1は、機能ブロックとしてヒヤリハット判定部F7を備える。ヒヤリハット判定部F7は、ドライバの生体情報(ここでは心拍数)の時間変化に基づいて、報知処理部F31が注意喚起したリスク状態に対してドライバがヒヤリハットしたか否かを判定する構成である。ヒヤリハット判定部F7は、CPU11によるソフトウェアの実行によって実現されていてもよいし、IC等を用いてハードウェアとして実現されていても良い。また、ソフトウェアとハードウェアの組み合わせによって実現されていても良い。
ドライバがヒヤリハットしたか否かの判定は、周知の方法によって実施されれば良い。例えば、注意喚起処理実行前の心拍数と、注意喚起処理実行後の心拍数を比較して、注意喚起処理実行後に一過性の心拍数の上昇が生じている場合に、ドライバはヒヤリハットしたと判定する。一過性の心拍数の上昇とは、心拍数が一時的に所定の閾値以上高くなる変化を指す。また、注意喚起処理を実行してから一定時間(例えば5秒)以内に、上述した一過性の心拍数の上昇が生じなかった場合にはヒヤリハットしなかったと判定する。
なお、生体情報として呼吸の間隔(換言すれば呼吸の速度)を用いる場合には、注意喚起処理実行前の呼吸間隔と比べて、注意喚起処理後の呼吸間隔が短くなっている場合に、ヒヤリハットしたと判定すればよい。また、生体情報として呼吸の間隔(換言すれば呼吸の速度)を用いる場合には、注意喚起処理実行前の呼吸間隔と比べて、注意喚起処理後の呼吸間隔が短くなっている場合に、ヒヤリハットしたと判定すればよい。生体情報として呼吸の深さ(換言すれば呼吸の振幅)を用いる場合には、注意喚起処理実行前の呼吸の深さと比べて、注意喚起処理後の呼吸の深さが浅くなっている場合に、ヒヤリハットしたと判定すればよい。
支援態様調整部F6は、依存度評価部F5によって依存度が、依存度推定関連処理を実施する前のレベルとは異なるレベルに設定された場合(つまり依存度の評価レベルに変化があった場合)、報知態様パラメータを、その新たな依存度に応じた値に設定する。また、依存度の評価レベルに変更がなかった場合には、ヒヤリハットの有無に応じて報知態様を調整する。
図8は、ヒヤリハットの有無に応じた報知態様の調整量の一例を示した図である。依存度がレベル1やレベル2となっている場合において、注意喚起処理後にドライバがヒヤリハットした場合とは、リスク状況自体に驚いたというよりも、注意喚起処理として出力された警報音等に対して驚いた可能性がある。そのため、依存度がレベル1やレベル2となっている場合にヒヤリハットが検出された場合には、刺激強度を本来の刺激強度よりも所定量弱める調整を行う。なお、ここでの本来の刺激強度とは、依存度に応じた本来の(換言すれば未調整の)刺激強度に相当する。
一方、依存度がレベル1となっている場合にドライバがヒヤリハットしなかった場合、レベル2本来の報知態様が、ドライバにとって適切な態様となっている可能性が高い。故に、報知態様の調整は実施しない。ただし、依存度がレベル2となっている場合にドライバがヒヤリハットしなかった場合は、レベル2本来の報知態様にドライバが慣れてしまっている可能性がある。故に、刺激強度をレベル2本来の刺激強度よりも強める調整を行う。
依存度がレベル3やレベル4となっている場合において、注意喚起処理後にドライバがヒヤリハットした場合とは、注意喚起処理として出力された警報音等に対して驚いたというよりも、リスク状態自体に驚いた可能性のほうが高い。依存度がレベル3に設定されている場合においてドライバがヒヤリハットした場合、ドライバの依存度は高いものの、当該ヒヤリハットによって依存度が下がることが期待できる。故に、報知態様はレベル3本来の報知態様のままとする(つまり調整しない)。
依存度がレベル4に設定されている場合においてドライバがヒヤリハットした場合、ドライバの依存度は高いものの、当該ヒヤリハットによって依存度が下がることが期待できる。故に、刺激強度はレベル4本来の刺激強度のままとする。ただし、報知タイミングに関してはレベル4本来の報知タイミングよりも所定量早める調整を行う。このような設定では、ドライバ自身で周辺状況を認識及び判断する時間が長くなり、自分自身の手でリスク対象物との衝突を回避しようとする機会が増える。その結果、運転支援システム100に頼らずに、自分自身の手でリスク状態を回避しようとするドライバの意識が強まることが期待できる。つまり、上記設定によれば依存度をより一層低減させる効果が期待できる。
依存度がレベル3に設定されている場合において、ドライバがヒヤリハットしなかった場合、レベル3本来の報知態様にドライバが慣れてしまっている可能性がある。故に、刺激強度をレベル3本来の刺激強度よりも強める調整を行う。また、報知タイミングもレベル3本来の報知タイミングよりも遅くする調整を行う。
依存度がレベル4に設定されている場合において、ドライバがヒヤリハットしなかった場合、ドライバが注意喚起処理に慣れきっている可能性がある。故に、注意喚起処理の実行自体を停止し、ドライバに自分自身で周辺を確認する習慣を身につけるように促す。
変形例1として開示した上記の構成においても上述した実施形態と同様の効果を奏する。また、変形例1の構成によれば、実施形態に比べて、ドライバの依存度をより効果的に適正なレベルへと移行させることができる。
[変形例2]
上述した実施形態や変形例1では、依存度に応じて報知態様パラメータを調整する態様を開示したが、依存度に応じて、車両制御部F32が車両制御を実施する際の態様を規定する車両制御パラメータを調整しても良い。車両制御パラメータは、支援パラメータの一部であって、支援パラメータ記憶部M2に保存されている。
車両制御パラメータは、車両制御の内容毎に設定されている。例えば、減速制御についての車両制御パラメータとしては、減速を開始するTTCの値(換言すれば制御介入条件)や、減速度などがある。依存度が高いほど減速を開始するタイミングを遅くするとともに、減速度を大きくすれば良い。また、操舵制御についての車両制御パラメータとしては、操舵制御を開始するTTCの値や、操舵角速度などがある。依存度が高いほど操舵制御を開始するタイミングを遅くするとともに回転角速度を大きくすれば良い。
[変形例3]
リスク検出部F2は、ドライバが速度超過などの不安全な運転操作を実施している状態をリスク状態として検出してもよい。具体的には、リスク検出部F2は、自車両の走行速度が制限速度よりも所定速度(例えば20km/h)超過している場合、自車両の走行状態がリスク状態となっていると判定する。自車両の走行速度が制限速度を超過している場合には、制限速度を遵守して走行している場合よりも、事故の発生確率が高くなるためである。なお、自車両の走行速度は車両状態センサ3としての車速センサから取得すれば良い。
この変形例における報知処理部F31は、制限速度を超過している状態が検出された場合には、その旨を示す警報音又は音声メッセージを注意喚起情報としてスピーカ5から出力することによって報知する。
制限速度を超過していることを示す情報出力に対する適応操作とは、走行速度を落とすための操作である。例えば、アクセルペダルから足を離す操作や、エンジンブレーキを作動させる操作、ブレーキペダルに足を載せる操作、ブレーキペダルを踏み込む操作などである。各操作は、周知の車載センサによって検出されれば良い。なお、走行速度が制限速度まで減速した場合に、速度超過状態に対する適応操作が実施されたと判定しても良い。
また、上記の適応操作を実施するための準備行動とは、メータ等に示される走行速度の確認や、現在走行している道路の制限速度の確認、周辺の交通状況の確認などである。メータ等に示される走行速度を確認したか否かは、ドライバの視線方向によって特定されれば良い。ドライバの視線方向は、顔カメラや上半身カメラによって特定されればよい。
[変形例4]
上述した実施形態では、依存度をレベル1〜4の4段階で評価する態様を開示したがこれに限らない。例えば依存度をレベル1〜3の3段階で評価してもよい。また、適応操作フラグがオンに設定されており且つ準備行動フラグがオフに設定されている場合と、適応操作フラグがオフに設定されており且つ準備行動フラグがオンに設定されている場合とを、同じ依存度(具体的にはレベル2)に設定してもよい。準備行動をせずに適応操作をしたということは、運転支援ECU1による情報提示を過度に信頼している状態を示唆するためである。図9は上述した判定規則の一例を図に表したものである。
また、図10に示すように適応操作フラグがオフに設定されており且つ準備行動フラグがオンに設定されている場合の依存度は、準備行動としてリスク対象方向をドライバが目視したか否かによって決定されても良い。具体的には、準備行動としてドライバがリスク対象方向を目視していない場合には、依存度を最も高いレベル(例えばレベル3)に設定する。
一方、準備行動としてリスク対象方向をドライバが目視している場合には、依存度を最も低いレベル(つまりレベル1)に設定する。リスク対象方向をドライバが目視しているにも関わらず、ドライバが適応操作を実施しなかった場合には、リスク検出部F2によるリスク状態の検出が誤りである可能性があるためである。ただし、最終的に車両制御部F32による車両制御が実行された場合には、リスク検出部F2の検出結果が正しかったことを意味するため、依存度はレベル3に設定されることが好ましい。以上の構成によれば、より適切に依存度を判定する事ができる。
また、ドライバが準備行動を実施した後に適応操作を実施した場合の中でも、ドライバがリスク存在方向を視認した場合と、ドライバがサブ準備行動のみを実施した場合とで、依存度を変更しても良い。例えば図11に示すように、リスク存在方向を視認せずにサブ準備行動のみを実施してから適応操作を実施した場合の依存度を、リスク存在方向を視認してから適応操作を実施した場合に比べて高いレベルに設定する。もちろん、一切の準備行動を取らずに適応操作を実施した場合の依存度は、リスク存在方向を視認せずにサブ準備行動のみを実施してから適応操作を実施した場合よりも高いレベルに設定すればよい。