JP6662080B2 - ドライバ状態判定装置 - Google Patents

Description

本発明は、ドライバの状態を判定するドライバ状態判定装置に関するものである。

従来、車両のドライバの状態を判定する技術が知られている。例えば、特許文献１には、ドライバの運転操作に起因して変化する車速及びステア角といった車両信号から、ドライバの漫然状態を判定する技術が開示されている。

特開２０１５−１１５３６号公報

しかしながら、特許文献１に開示の技術では、車両の加速、制動、及び操舵の一部若しくは全部を自動で制御する自動運転について考慮されていない。よって、自動運転を実施できる車両において、以下のような問題点が生じる。例えば、操舵を自動で制御する自動運転が行われている場合のステア角は、ドライバの運転操作に起因して変化するものではない。よって、自動運転の実施時にこのステア角から判定したドライバ状態は、実際のドライバ状態と乖離してしまう可能性が高い。また、加速及び／又は制動を自動で制御する自動運転が行われている場合の車速は、ドライバの運転操作に起因して変化するものではない。よって、自動運転の実施時にこの車速から判定したドライバ状態も、実際のドライバ状態と乖離してしまう可能性が高い。このように、特許文献１に開示の技術では、自動運転の実施時においてドライバ状態の判定精度が低下してしまうという問題点が生じる。

本発明は、上記従来の問題点に鑑みなされたものであって、その目的は、ドライバ状態の判定に車両信号を用いることができるドライバ状態判定装置において、車両が自動運転の実施時であってもドライバ状態の判定精度の低下を抑えることにある。

上記目的は独立請求項に記載の特徴の組み合わせにより達成され、また、下位請求項は、発明の更なる有利な具体例を規定する。特許請求の範囲に記載した括弧内の符号は、一つの態様として後述する実施形態に記載の具体的手段との対応関係を示すものであって、本発明の技術的範囲を限定するものではない。

上記目的を達成するために、本発明の第１のドライバ状態判定装置は、加速、制動、及び操舵の少なくともいずれかを自動で制御する自動運転を行うことができる車両で用いられ、自動運転の実施不実施は切り替えられるものであり、車両のドライバの状態であるドライバ状態を判定できる、車両の車両信号を取得する車両信号取得部（４０４）と、ドライバ状態を判定できる情報として車両信号以外の情報である判定用情報を取得する判定用情報取得部（４０２，４０３）と、車両信号取得部で取得した車両信号と判定用情報取得部で取得した判定用情報との少なくともいずれかを用いてドライバ状態を判定する状態判定部（４０６，４０６ａ）とを備え、状態判定部は、自動運転の不実施時には、車両信号を用いてドライバ状態を判定する一方、自動運転の実施時には、車両信号を用いずにドライバ状態を判定する。
上記目的を達成するために、本発明の第２のドライバ状態判定装置は、加速、制動、及び操舵の少なくともいずれかを自動で制御する自動運転を行うことができる車両で用いられ、自動運転の実施不実施は切り替えられるものであり、車両のドライバの状態であるドライバ状態を判定できる、車両の車両信号を取得する車両信号取得部（４０４）と、ドライバ状態を判定できる情報として車両信号以外の情報である判定用情報を取得する判定用情報取得部（４０２，４０３）と、車両信号取得部で取得した車両信号と判定用情報取得部で取得した判定用情報との少なくともいずれかを用いてドライバ状態を判定する状態判定部（４０６，４０６ａ）とを備え、自動運転は、自動化のレベルを複数段階に切り替えられるものであり、状態判定部は、自動運転の実施時には、自動運転の不実施時に比べて、車両信号よりも判定用情報の重みを大きくしてドライバ状態を判定し、自動運転の自動化のレベルが上がるほど、車両信号よりも判定用情報の重みを大きくしてドライバ状態を判定する。

これによれば、自動運転の実施時には、自動運転の不実施時に比べて、車両信号よりも判定用情報の重みを大きくしてドライバ状態を判定するので、ドライバの運転操作に起因して変化するものではない車両信号による実際のドライバ状態と判定結果との乖離を抑えることが可能になる。よって、自動運転の実施時であっても、ドライバ状態の判定精度の低下を抑えることが可能になる。

ドライバ状態判定システム１の概略的な構成の一例を示す図である。 ウェアラブルデバイス２の概略的な構成の一例を示す図である。 車両側ユニット３の概略的な構成の一例を示す図である。 実施形態１におけるＨＣＵ４０の概略的な構成の一例を示す図である。 自動化レベルに応じた各パラメータの重みの一例を説明するための図である。 ＨＣＵ４０でのドライバ状態判定関連処理の流れの一例を示すフローチャートである。 自動化レベル及び覚醒状態に応じた刺激の態様の一例を説明するための図である。 実施形態２におけるＨＣＵ４０ａの概略的な構成の一例を示す図である。

図面を参照しながら、開示のための複数の実施形態及び変形例を説明する。なお、説明の便宜上、複数の実施形態及び変形例の間において、それまでの説明に用いた図に示した部分と同一の機能を有する部分については、同一の符号を付し、その説明を省略する場合がある。同一の符号を付した部分については、他の実施形態及び／又は変形例における説明を参照することができる。

（実施形態１）
＜ドライバ状態判定システム１の概略構成＞
以下、本発明の実施形態１について図面を用いて説明する。図１に示すように、ドライバ状態判定システム１は、ウェアラブルデバイス２及び車両側ユニット３を含んでいる。

ウェアラブルデバイス２は、ユーザに装着されて、そのユーザの生体信号を計測する。ウェアラブルデバイス２としては、ユーザの腕に装着する腕時計型、ユーザの頭部に眼鏡と同様にして装着する眼鏡型等があるが、以下では腕時計型を例に挙げて説明を行う。

車両側ユニット３は、車両ＨＶで用いられて、ウェアラブルデバイス２と無線通信を行う。また、車両側ユニット３は、車両ＨＶのドライバの状態（以下、ドライバ状態）を推定したり、ドライバ状態を提示したり、ドライバ状態を改善する刺激をドライバに与えたりする。

＜ウェアラブルデバイス２の概略構成＞
続いて、図２を用いてウェアラブルデバイス２の概略構成を説明する。ウェアラブルデバイス２は、図２に示すように、主制御部２０、計測関連部２１、操作入力部２２、通信部２３、提示部２４、及び刺激部２５を備えている。

計測関連部２１は、図２に示すように、加速度センサ２１１、体動判定部２１２、脈波センサ２１３、心拍計測部２１４、及び血圧計測部２１５を備えている。

加速度センサ２１１は、起動された場合に、ウェアラブルデバイス２に生じる加速度を電圧値として逐次計測するセンサである。つまり、加速度センサ２１１は、ユーザの生体信号として、ウェアラブルデバイス２を装着したユーザの部位に生じる加速度を計測する。例えば、加速度センサ２１１は、ウェアラブルデバイス２の電源がオンになったときに主制御部２０の指示に従って起動する構成とすればよい。加速度センサ２１１としては、互いに直交する３軸それぞれの軸方向に沿った加速度を計測可能な３軸加速度センサを用いればよい。なお、加速度センサ２１１としては、１軸加速度センサ、２軸加速度センサを用いる構成としてもよい。加速度センサ２１１は、計測した加速度を体動判定部２１２に出力する。

体動判定部２１２は、加速度センサ２１１で計測した加速度をもとに、ユーザの体動の有無を判定する。一例として、３軸の加速度のいずれかでも閾値以上となった場合に、ユーザの体動ありと判定し、３軸の加速度のいずれも閾値未満となった場合に、ユーザの体動なしと判定する。ここで言うところの閾値とは、例えばユーザの体動なしの場合のノイズを体動ありと判定しない程度に設定された任意の値とすればよい。なお、３軸それぞれの閾値が異なる構成であってもよい。

脈波センサ２１３は、起動された場合に、ウェアラブルデバイス２を装着した部位におけるユーザの脈波を検出する。例えば、脈波センサ２１３は、体動判定部２１２で体動なしと判定している場合に作動する構成とすればよい。脈波センサ２１３は、計測周期（言い換えるとサンプリングレート）を変更可能な脈波センサであって、サンプリングレートを例えば２０Ｈｚの低周期と２００Ｈｚの高周期とに切り替えることができるものとする。このような脈波センサ２１３としては、例えば光電式脈波センサ、インピーダンス式脈波センサ等を用いることができる。

心拍計測部２１４は、脈波センサ２１３で逐次検出される容積脈波の信号に周知の信号処理を行い、容積脈波からユーザの心拍数を計測する。計測した心拍数は主制御部２０へ出力する。血圧計測部２１５は、脈波センサ２１３で逐次検出される容積脈波の信号に周知の信号処理を行い、容積脈波からユーザの血圧を計測する。計測した血圧は主制御部２０へ出力する。

容積脈波の信号をもとに血圧を計測するには、心拍数の計測に必要なサンプリングレートよりもサンプリングレートを大きくして、容積脈波の波形をきれいにとることが必要になる。よって、脈波センサ２１３で検出される容積脈波を用いて血圧を計測する場合には、心拍数と血圧とのうちの心拍数のみを計測する場合よりもサンプリングレートを大きくする構成とすればよい。本実施形態の例では、心拍数と血圧とのうちの心拍数のみの計測はサンプリングレート２０Ｈｚで行い、血圧の計測はサンプリングレート２００Ｈｚで行う構成とすればよい。

操作入力部２２は、ユーザが操作するスイッチ群である。操作入力部２２はメカニカルなスイッチであってもよいし、タッチパネル式のスイッチであってもよい。一例として、ウェアラブルデバイス２の電源をオン状態とオフ状態との間で切り替える電源スイッチ、生体信号の計測開始を指示する計測開始スイッチ、計測結果の提示を指示する提示開始スイッチ等を有している。計測開始スイッチ及び提示開始スイッチは、複数の生体信号の個々を対象として指定できる構成としてもよい。

なお、ウェアラブルデバイス２の電源のオンオフは、操作入力部２２へのユーザからの操作入力によって切り換えない構成としてもよい。例えば、ウェアラブルデバイス２の着脱に応じて自動的に切り換わる構成としてもよい。

通信部２３は、車両側ユニット３の後述する近距離通信機５との間で近距離無線通信を行う。通信部２３は、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＺｉｇＢｅｅ（登録商標）等の近距離無線通信規格に沿って信号を送受信する構成とすればよいが、以下ではＢｌｕｅｔｏｏｔｈの規格に沿って信号を送受信する場合を例に挙げて説明を行う。なお、消費電力低減の観点からは、Ｂｌｕｅｔｏｏｔｈ Ｌｏｗ Ｅｎｅｒｇｙの規格に沿って信号を送受信する構成とすることがより好ましい。

提示部２４は、主制御部２０の指示に従って情報提示を行う。情報提示は、表示装置によって行ってもよいし、音声出力装置によって行ってもよい。一例として、計測関連部２１で計測されるユーザの心拍数、血圧といった生体信号の計測値を表示すればよい。

刺激部２５は、主制御部２０の指示に従って、ウェアラブルデバイス２を装着しているユーザに対して刺激を行う。一例として、振動子を振動させることで刺激を行う構成としてもよいし、アラーム等の警報を出力することで刺激を行う構成としてもよい。

主制御部２０は、揮発性メモリ、不揮発性メモリ、Ｉ／Ｏ、及びこれらを接続するバス
を備え、不揮発性メモリに記憶された制御プログラムを実行することで各種の処理を実行
する。例えば、ウェアラブルデバイス２の電源がオンになったときに、加速度センサ２１１を起動させる。また、操作入力部２２のうちの計測開始スイッチが操作された場合に、脈波センサ２１３を起動させる。他にも、操作入力部２２のうちの提示開始スイッチが操作された場合に、計測関連部２１で計測した生体信号の計測値を提示部２４に提示させる。また、計測関連部２１で計測した心拍数、血圧といった生体信号を通信部２３から車両側ユニット３へ送信させる。さらに、車両側ユニット３から通信部２３を介して受信した要求に従って、刺激部２５に刺激を行わせる。なお、主制御部２０が実行する機能の一部又は全部を、一つ或いは複数のＩＣ等によりハードウェア的に構成してもよい。

＜車両側ユニット３の概略構成＞
続いて、図３を用いて車両側ユニット３の概略構成を説明する。車両側ユニット３は、車両ＨＶに搭載されるものであり、図３に示すように、ＨＭＩ（Human Machine Interface）システム４、近距離通信機５、ＩＴＳ（Intelligent Transport Systems）通信機６、ＡＤＡＳ（Advanced Driver Assistance Systems）ロケータ７、周辺監視システム８、及び車両制御ＥＣＵ９を含んでいる。ＨＭＩシステム４、近距離通信機５、ＩＴＳ通信機６、ＡＤＡＳロケータ７、周辺監視システム８、及び車両制御ＥＣＵ９は、例えば車内ＬＡＮに接続されており、通信によって互いに情報をやり取りすることができる。

近距離通信機５は、近距離無線通信規格に沿って信号を送受信する。近距離通信機５は、通信範囲が車両ＨＶの車室内に止まることが好ましく、例えば最大通信距離が１ｍ未満程度となるようにすればよい。近距離通信機５は、車両ＨＶのドライバが装着するウェアラブルデバイス２との間で無線通信を行う。本実施形態の例では、近距離通信機５は、Ｂｌｕｅｔｏｏｔｈ Ｌｏｗ Ｅｎｅｒｇｙの規格に沿って信号を送受信する。

以下では、ユーザが装着するウェアラブルデバイス２と近距離通信機５とのペアリングが実行済みであるものとして以降の説明を行う。また、車両ＨＶのドライバとなったユーザが装着しているウェアラブルデバイス２以外のペアリング済みのウェアラブルデバイス２が車両ＨＶの車室内にある場合でも、ドライバのウェアラブルデバイス２と近距離通信機５との接続が、例えばドライバの操作入力によって選択されているものとして以降の説明を行う。

ＩＴＳ通信機６は、車両ＨＶの周辺車両に搭載された車載通信機及び／又は路側に設置された路側機との間で、無線通信を行う。例えばＩＴＳ通信機６は、車載通信機との車車間通信、路側機との路車間通信により、車両ＨＶの周辺車両の位置情報及び走行速度情報等を取得する。ＩＴＳ通信機６は、取得した情報を車内ＬＡＮへ出力する。

ＡＤＡＳロケータ７は、ＧＮＳＳ受信機、３Ｄジャイロセンサ等の慣性センサ、地図データを格納するメモリを備えている。ＧＮＳＳ（Global Navigation Satellite System）受信機は、複数の人工衛星からの測位信号を受信する。３Ｄジャイロセンサは、例えば３軸ジャイロセンサ及び３軸加速度センサを備える。

ＡＤＡＳロケータ７は、ＧＮＳＳ受信機で受信する測位信号と、慣性センサの計測結果とを組み合わせることにより、車両ＨＶの位置を測位する。ＡＤＡＳロケータ７は、メモリから、車両ＨＶの進路前方のリンクデータ、ノードデータ、道路形状、構造物等の地図データを読み出す。ＡＤＡＳロケータ７は、車両ＨＶの位置と、読み出した進路前方の地図データとを、車内ＬＡＮへ逐次出力する。なお、地図データは、車両ＨＶに搭載されたＤＣＭ（Data Communication Module）といったテレマティクス通信に用いられる車載通信モジュールを用いて取得する構成としてもよい。

周辺監視システム８は、周辺監視ＥＣＵ８０及び周辺監視センサ８１を備えている。周辺監視システム８は、歩行者、人間以外の動物、自転車、オートバイ、及び他車等の移動物体、さらに路上の落下物、ガードレール、縁石、及び樹木等の静止物体といった障害物を検出する。他にも、走行区画線、停止線等の路面標示も検出する。

周辺監視センサ８１は、車両ＨＶ周囲の所定範囲を撮像する周辺監視カメラ、車両ＨＶ周囲の所定範囲に探査波を送信するミリ波レーダ、ソナー、ＬＩＤＡＲ（Light Detection and Ranging/Laser Imaging Detect ion and Ranging）等のセンサである。周辺監視カメラとしてはステレオカメラを用いる構成であっても、単眼カメラを用いる構成であってもよい。周辺監視カメラは、逐次撮像する撮像画像を、周辺監視ＥＣＵ８０へ逐次出力する。ソナー、ミリ波レーダ、ＬＩＤＡＲ等の探査波を送信するセンサは、障害物によって反射された反射波を受信した場合に得られる受信信号に基づく走査結果を周辺監視ＥＣＵ８０へ逐次出力する。

周辺監視センサ８１としては、単一の種類のセンサのみを用いる構成としてもよいし、複数種類のセンサを用いる構成としてもよい。また、車両ＨＶ前方のセンシングを周辺監視カメラとミリ波レーダとを併用して行う等、複数種類の周辺監視センサ８１が重複したセンシング範囲を有する構成としてもよい。

周辺監視ＥＣＵ８０は、ＣＰＵ、揮発性メモリ、不揮発性メモリ、Ｉ／Ｏ、これらを接続するバスを備え、不揮発性メモリに記憶された制御プログラムを実行することで各種の処理を実行する。なお、周辺監視ＥＣＵ８０が実行する機能の一部または全部を、一つあるいは複数のＩＣ等によりハードウェア的に構成してもよい。

周辺監視ＥＣＵ８０は、周辺監視センサ８１でのセンシング結果から、車両ＨＶの走行環境を認識する。例えば、周辺監視センサ８１でのセンシング結果から、車両ＨＶ周辺に存在する物体について、車両ＨＶからの距離、車両ＨＶに対する相対位置、車両ＨＶに対する相対速度等を検出する。また、周辺監視ＥＣＵ８０は、周辺監視カメラで撮像した撮像画像、ＬＩＤＡＲでのセンシング結果から、走行区画線等の路面標示、車両ＨＶに対する路面標示の位置等を検出する構成としてもよい。

また、周辺監視ＥＣＵ８０は、周辺監視センサ８１のセンシング結果以外を用いて車両ＨＶの走行環境を認識してもよい。例えば、ＩＴＳ通信機６を介した車車間通信及び／又は路車間通信によって得られた他車の位置、速度等から、車両ＨＶの周辺に存在する他車について、車両ＨＶからの距離、車両ＨＶに対する相対位置、車両ＨＶに対する相対速度等を検出してもよい。周辺監視ＥＣＵ８０は、検出した各種の情報を、監視情報として車内ＬＡＮに出力する。

車両制御ＥＣＵ９は、車両ＨＶの加減速制御及び／又は操舵制御を行う電子制御装置である。車両制御ＥＣＵ９としては、操舵制御を行う操舵ＥＣＵ、加減速制御を行うパワーユニット制御ＥＣＵ及びブレーキＥＣＵ等がある。車両制御ＥＣＵ９は、車両ＨＶに搭載されたアクセルポジションセンサ、ブレーキ踏力センサ、舵角センサ、車速センサ、加速度センサ等の各センサから出力される検出信号を取得し、電子制御スロットル、ブレーキアクチュエータ、ＥＰＳ（Electric Power Steering）モータ等の各走行制御デバイスへ制御信号を出力する。また、車両制御ＥＣＵ９は、上述の各センサの検出信号（以下、車両信号）を車内ＬＡＮへ出力可能である。

また、車両制御ＥＣＵ９は、周辺監視ＥＣＵ８０で検出した監視情報をもとに、車両ＨＶの加速、制動、及び／又は操舵を自動で制御することで、ドライバによる運転操作の代行を行う自動運転機能を備えている。自動運転機能の一例としては、周辺監視ＥＣＵ８０から取得する先行車の監視情報をもとに駆動力及び制動力を調整することで、先行車との目標車間距離を維持するように車両ＨＶの走行速度を制御するＡＣＣ（Adaptive Cruise Control）機能がある。また、周辺監視ＥＣＵ８０から取得する進行方向の走行区間線の監視情報をもとに、走行区画線への接近を阻む方向への操舵力を発生させることで、走行中の車線を維持して車両ＨＶを走行させるＬＫＡ（Lane Keeping Assist）機能がある。

他にも、周辺監視ＥＣＵ８０から取得する進行方向の走行区画線の監視情報、及び隣接車線の他車の監視情報をもとに、隣接車線へと車両ＨＶを自動で移動させるＬＣＡ（Lane Change Assist）機能がある。さらに、周辺監視ＥＣＵ８０から取得する車両ＨＶ前方の監視情報をもとに、制動力を発生させることで、車両ＨＶを強制的に自動減速するＡＥＢ（Autonomous Emergency Braking）機能もある。ＡＥＢ機能は、一例としては、車両ＨＶ前方の物体に対するＴＴＣ（time to collision）が例えば５ｓｅｃ等の設定値を下回り、緊急制御条件が成立した場合に、車両ＨＶを強制的に自動減速させる。また、自動運転機能の一例として、車両ＨＶを自動で合流させる自動合流の機能、緊急時に路肩等に自動で停車させる自動退避の機能等もある。なお、ここで述べたのは、あくまで一例であり、自動運転機能として他の機能を備えている構成としてもよい。

車両制御ＥＣＵ９は、運転操作の自動化のレベル（以下、自動化レベル）を複数段階に切り替えられるものとする。実施形態１では、自動運転の実施不実施を切り替えられるとともに、自動運転における自動化レベルも切り替えられる場合を例に挙げて説明を行う。実施形態１では、ＮＨＴＳＡ（National Highway Traffic Safety Administration）が定義付けている自動化レベルの分類に沿った、自動化レベル０（No-Automation）、自動化レベル１（Function-specific Automation）、自動化レベル２（Combined Function Automation）、自動化レベル３（Limited Self-Driving Automation）、自動化レベル４（Full Self-Driving Automation）の５段階に切り替えられるものとする。

自動化レベル０は、車両ＨＶのブレーキ、ステアリング、スロットル、原動力といった主操縦系統について自動化を行わずにドライバが全て操作する段階である。言い換えると、加速、制動、及び操舵のいずれについても自動で制御しない自動運転不実施の段階である。

自動化レベル１は、車両ＨＶの主操縦系統の１つを自動化した機能を単独で実行する段階である。言い換えると、加速、制動、及び操舵のいずれかを自動で制御する、特定機能の自動化の段階である。特定機能の自動化の段階の一例としては、ＡＣＣ機能、ＬＫＡ機能、ＡＢＥ機能を単独で実行する段階である。

自動化レベル２は、車両ＨＶの主操縦系統の１つを自動化した機能を複合して実行する段階である。言い換えると、加速、制動、及び操舵のうちの複数を自動で制御する、複合機能の自動化の段階である。複合機能の自動化の段階の一例としては、ＡＣＣ機能とＬＫＡ機能とを併用して実行したり、ＡＣＣ機能とＬＣＡ機能とを併用して実行したりする段階である。

自動化レベル３は、車両ＨＶの主操縦系統の全てを自動化し、ドライバが運転すべき交通状況への変化時に限ってドライバが運転操作を行う段階である。言い換えると、緊急時を除いて、加速、制動、及び操舵の全てを自動で制御する、半自動運転の段階である。

自動化レベル４は、車両ＨＶの主操縦系統の全てを自動化し、走行中のいかなるときもドライバが運転操作を行う必要にない段階である。言い換えると、緊急時にも、加速、制動、及び操舵の全てを自動で制御する、完全自動運転の段階である。自動化レベル１〜自動化レベル４については、加速、制動、及び操舵の少なくともいずれかを自動で制御する自動運転実施の段階と言うこともできる。

車両制御ＥＣＵ９での自動化レベルの切り替えは、操作デバイス４２へのドライバによる入力操作に従って行われる構成とすればよい。他にも、周辺監視ＥＣＵ８０から得られる監視情報をもとに判定される交通状況、周辺監視センサ８１でのセンシングの不具合等に応じて、車両制御ＥＣＵ９で自律的に行われる構成としてもよい。また、自動化レベルを切り替える場合の段階分けは、前述した例に限らない。例えば、自動運転不実施の段階、一部の運転操作を自動で行う段階、及び全ての運転操作を自動で行う段階といった段階分けであってもよいし、さらに他の段階分けであってもよい。

ＨＭＩシステム４は、自車のドライバからの入力操作を受け付けたり、自車のドライバに向けて情報を提示したり、自車のドライバの状態を監視したり、自車のドライバに刺激を与えたりする。ＨＭＩシステム４については、以下で詳述する。

＜ＨＭＩシステム４の概略構成＞
続いて、図３を用いて、ＨＭＩシステム４の概略構成を説明する。図３に示すように、ＨＭＩシステム４は、ＨＣＵ（Human Machine Interface Control Unit）４０、ドライバモニタカメラ４１、操作デバイス４２、表示装置４３、音声出力装置４４、及びアクチュエーション装置４５を備えている。

ドライバモニタカメラ４１は、近赤外光源及び近赤外カメラを含んでいる。ドライバモニタカメラ４１は、近赤外カメラを車両ＨＶの運転席側に向けた姿勢にて、例えばインスツルメントパネルの上面に配置される。ドライバモニタカメラ４１では、近赤外光源によって近赤外光を照射されたドライバの顔を含む範囲を、近赤外カメラによって撮影する。近赤外カメラによるドライバの顔を含む範囲の撮像画像（以下、ドライバ画像）は、ＨＣＵ４０へ出力される。

操作デバイス４２は、車両ＨＶのドライバが操作するスイッチ群である。操作デバイス４２は、各種の設定を行うために用いられる。例えば、操作デバイス４２としては、車両ＨＶのステアリングのスポーク部に設けられたステアリングスイッチ等がある。

表示装置４３としては、例えばコンビネーションメータ、ＣＩＤ（Center Information Display）、ＨＵＤ（Head-Up Display）等がある。コンビネーションメータは、車両ＨＶの運転席前方に配置される。ＣＩＤは、車両ＨＶの車室内にてセンタクラスタの上方に配置される。コンビネーションメータ及びＣＩＤは、ＨＣＵ４０から取得した画像データに基づいて、情報提示のための種々の画像をディスプレイの表示画面に表示する。ＨＵＤは、ＨＣＵ４０から取得した画像データに基づく画像の光を、車両ＨＶのウインドシールドに規定された投影領域に投影する。ウインドシールドによって車室内側に反射された画像の光は、運転席に着座するドライバによって知覚される。ドライバは、ＨＵＤによって投影された画像の虚像を、車両ＨＶの前方の外界風景と重ねて視認可能となる。

音声出力装置４４としては、例えばオーディオスピーカ等がある。オーディオスピーカは、車両ＨＶのドアの内張り内に配置される。オーディオスピーカは、再生する音声によって乗員への情報提示を行う。

アクチュエーション装置４５は、ドライバに対して刺激を行う。一例として、車両ＨＶのステアリングホイールに設けられた振動子を振動させることで、ステアリングホイールを握っているドライバの手に刺激を行う構成とすればよい。

ＨＣＵ４０は、ＣＰＵ、ＲＯＭ及びＲＡＭ等のメモリ、Ｉ／Ｏ、これらを接続するバスを備え、メモリに記憶された制御プログラムを実行することで各種の処理を実行する。例えば、ドライバモニタカメラ４１から取得したドライバ画像、車両ＨＶに搭載されたセンサで検出した車両信号、ウェアラブルデバイス２から近距離通信機５で受信した生体信号等のパラメータをもとに、ドライバ状態を判定する。ドライバ状態としては、運転不能状態、覚醒状態、脇見状態等がある。このＨＣＵ４０が請求項のドライバ状態判定装置に相当する。

また、ＨＣＵ４０は、判定したドライバ状態に応じて、表示装置４３及び／又は音声出力装置４４から情報提示を行わせたり、アクチュエーション装置４５からドライバに刺激を行わせたりする。なお、ＨＣＵ４０が実行する機能の一部または全部を、一つあるいは複数のＩＣ等によりハードウェア的に構成してもよい。

＜ＨＣＵ４０の概略構成＞
ここで、図４を用いて、ＨＣＵ４０の概略構成を説明する。図４に示すように、ＨＣＵ４０は、連携状況検出部４０１、生体信号取得部４０２、画像取得部４０３、車両信号取得部４０４、自動化レベル判定部４０５、ドライバ状態判定部４０６、提示制御部４０７、刺激制御部４０８、及び要求送信部４０９を備えている。

連携状況検出部４０１は、車両ＨＶのドライバのウェアラブルデバイス２が車室内に位置している状況を検出する。一例としては、近距離通信機５とドライバのウェアラブルデバイス２との間で通信確立してから通信確立が解除されるまでを、ドライバのウェアラブルデバイス２が車室内に位置している状況として検出する。通信確立してから通信確立が解除されるまでの状態には、通信確立して接続前の状態、通信確立して接続中となっている状態、及び未接続となったが速やかに接続中に復帰できる省電力状態が含まれる。

連携状況検出部４０１においてドライバのウェアラブルデバイス２が車室内に位置している状況が検出されるケースについて、以下で説明を行う。ウェアラブルデバイス２を装着したドライバが車両ＨＶに乗車し、ＡＣＣ電源をオンにすると、近距離通信機５が起動する。続いて、ドライバのウェアラブルデバイス２と近距離通信機５とがペアリング済みである場合であって、近距離通信機５との接続対象にこのウェアラブルデバイス２が選択された場合に、近距離通信機５とこのウェアラブルデバイス２との間で通信が確立して通信が開始される。この際に、連携状況検出部４０１においてドライバのウェアラブルデバイス２が車室内に位置している状況が検出される。一方、ドライバが車両ＨＶから降車するためにＡＣＣ電源をオフにすると、近距離通信機５の動作が終了し、ドライバのウェアラブルデバイス２と近距離通信機５との接続が解消される。この際に、連携状況検出部４０１においてドライバのウェアラブルデバイス２が車室内に位置している状況が検出されなくなる。

なお、ドライバのウェアラブルデバイス２が車室内に位置している状況の検出は、上述したような通信の状態以外にも、操作デバイス４２へのドライバによる所定の入力操作等を条件とする構成としてもよい。ここで言うところの所定の入力操作とは、ドライバのウェアラブルデバイス２とＨＣＵ４０との接続（詳しくは近距離通信機５を介した接続）を要求する旨の入力操作等である。

生体信号取得部４０２は、ウェアラブルデバイス２から近距離通信機５で受信する生体信号を逐次取得し、ドライバ状態判定部４０６に出力する。実施形態１の例では、生体信号は、心拍数及び血圧である。画像取得部４０３は、ドライバモニタカメラ４１から出力されるドライバ画像を逐次取得し、ドライバ状態判定部４０６に出力する。この生体信号取得部４０２及び画像取得部４０３が請求項の判定用情報取得部に相当する。車両信号取得部４０４は、車両ＨＶに搭載されたセンサで検出した車両信号を逐次取得し、ドライバ状態判定部４０６に出力する。一例として、車両信号は、車速センサで検出した車速、舵角センサで検出した操舵角等とする。

自動化レベル判定部４０５は、車両制御ＥＣＵ９での自動運転機能の実行状況をもとに、車両ＨＶにおける運転操作の自動化レベルを判定する。一例として、以下のように判定すればよい。自動運転機能が１つも実行されていない場合には、自動化レベル０と判定する。自動運転機能が単独で実行されている場合には、自動化レベル１と判定する。加速、制動、及び操舵のうちの２つを自動化するように自動運転機能が複合して実行されている場合には、自動化レベル２と判定する。加速、制動、及び操舵の全てを自動化するように自動運転機能が複合して実行されている場合であって、且つ、自動退避の機能が実行可能でない場合には、自動化レベル３と判定する。加速、制動、及び操舵の全てを自動化するように自動運転機能が複合して実行されている場合であって、且つ、自動退避の機能が実行可能である場合には、自動化レベル４と判定する。

なお、自動化レベルを切り替える場合の段階分けが実施形態１の例と異なる構成とした場合には、自動化レベル判定部４０５は、その段階分けに応じて自動化レベルを判定すればよい。例えば、自動化レベル０、自動化レベル１、自動化レベル２、自動化レベル３以上といった段階分けを行う構成では、以下のようにすればよい。例えば、自動化レベル０〜自動化レベル２までは前述したのと同様にして判定を行い、加速、制動、及び操舵の全てを自動化するように自動運転機能が複合して実行されている場合には自動化レベル３以上と判定する構成とすればよい。

また、自動運転不実施の段階、一部でも運転操作を自動で行う段階といった段階分けを行う構成においては、自動運転機能が１つでも実行されているか否かで自動化レベルを判定すればよい。また、自動運転不実施の段階、一部の運転操作を自動で行う段階、及び全ての運転操作を自動で行う段階といった段階分けを行う構成においては、以下のようにすればよい。例えば、自動運転機能が１つも実行されていない場合には、自動運転不実施と判定する。加速、制動、及び操舵のうちの１つ若しくは２つを自動化するように自動運転機能が実行されている場合には、一部の運転操作を自動で行う段階と判定する。加速、制動、及び操舵の全てを自動化するように自動運転機能が複合して実行されている場合には、全ての運転操作を自動で行う段階と判定する。

ドライバ状態判定部４０６は、ドライバモニタカメラ４１から取得したドライバ画像、車両ＨＶに搭載されたセンサで検出した車両信号、ウェアラブルデバイス２から近距離通信機５で受信した生体信号等のパラメータをもとに、ドライバ状態を判定する。このドライバ状態判定部４０６が請求項の状態判定部に相当する。ドライバ状態判定部４０６は、連携状況検出部４０１がドライバのウェアラブルデバイス２が車室内に位置している状況を検出している場合には、ドライバ画像及び車両信号に加え、生体信号も用いてドライバ状態を判定できるモードに切り替わる。一方、ドライバ状態判定部４０６は、連携状況検出部４０１がドライバのウェアラブルデバイス２が車室内に位置している状況を検出していない場合には、生体信号を用いずにドライバ状態を判定するモードに切り替わる。

また、ドライバ状態判定部４０６は、自動化レベル判定部４０５で判定した自動化レベルに応じて各パラメータの重みを変更して、ドライバ状態を判定する。一例としては、パラメータごとにドライバ状態を推定した後、重みの大きいパラメータから推定したドライバ状態がより優先されるようにドライバ状態を判定する構成とすればよい。以下では、ドライバ状態として運転不能異常状態及び覚醒状態を判定する場合を例に挙げて説明を行う。

まず、ドライバモニタカメラ４１から取得したドライバ画像からの運転不能状態、覚醒状態の推定は、一例として以下のようにすればよい。ドライバモニタカメラ４１から取得した撮像画像から、画像認識処理によって、ドライバの顔向き、ドライバの姿勢、瞼の開閉状態等を検出する。そして、検出した顔向き、ドライバの姿勢をもとに、運転不能状態を推定する。例えば、顔向きが下方向の状況が継続すること、ドライバの姿勢が崩れていることをもとに、失神といったドライバの運転不能を推定する。以下では、運転不能状態は、「運転可能」、「運転不能」の２段階である場合を例に挙げて説明を行う。

また、検出した瞼の開閉状態、ドライバの姿勢をもとに、覚醒状態を推定する。例えば、瞼の開閉の頻度からドライバの漫然状態を推定したり、瞼の開閉における振幅対速度から眠気の開始を推定したり、瞼の閉じた状態の継続時間から睡眠を推定したり、ドライバの姿勢の崩れから睡眠の深さを推定したりする。以下では、覚醒状態は、覚醒度の高い順から「覚醒」、「漫然」、「眠気」、「浅い睡眠」、「深い睡眠」の５段階である場合を例に挙げて説明を行う。

車両ＨＶに搭載されたセンサで検出した車両信号からの運転不能状態、覚醒状態の推定は、一例として以下のようにすればよい。例えば車速センサで逐次検出する車速、舵角センサで逐次検出する操舵角の標準偏差が閾値を越えたか否かで運転不能を推定すればよい。また、車速センサで逐次検出する車速、舵角センサで逐次検出する操舵角の変化パターンから、覚醒状態を推定すればよい。一例として、車速、操舵角の時系列データについて周波数分析を行い、時系列データの周波数成分のうち特定周波数の積分値に基づいて、車両ＨＶのふらつき及び／又はドライバの運転操作の滑らかさを判断することで、覚醒度を検出すればよい。

ウェアラブルデバイス２から近距離通信機５で受信した生体信号からの運転不能状態、覚醒状態の推定は、一例として以下のようにすればよい。例えば、心拍数及び血圧と運転不能状態とを予め対応付けたマトリクスをもとに、運転不能状態を推定する構成とすればよい。また、心拍数及び血圧と覚醒状態とを予め対応付けたマトリクスをもとに、覚醒状態を推定する構成とすればよい。心拍変動の揺らぎ解析によって覚醒状態を推定する構成としてもよい。

なお、各パラメータによる覚醒状態の推定では、パラメータごとに覚醒度の段階の対応がとれていれば、パラメータごとの覚醒度の段階分けの数が異なっていてもよい。一例として、ドライバ画像からの覚醒状態の推定は、「覚醒」、「漫然」、「眠気」、「浅い睡眠」、「深い睡眠」の５段階である一方、車両信号からの覚醒状態の推定は、「覚醒」、「漫然」、「浅い睡眠」の３段階である等の構成であってもよい。

続いて、ドライバ状態判定部４０６での、自動化レベル判定部４０５で判定した自動化レベルに応じた各パラメータの重みについての説明を行う。自動化レベルに応じた各パラメータの重みについては、自動化レベルが上がるほど、車両信号の重みが小さくなるようにすればよい。また、自動化レベルが上がるほど、生体信号の重みが大きくなるようにすればよい。

一例として、自動化レベル判定部４０５で判定した自動化レベルをもとに、自動化レベルとパラメータとの組み合わせごとに重要度を対応付けた対応関係から、各パラメータの重要度を設定する。具体例としては、図５に示すような、自動化レベルとパラメータとの組み合わせごとに重要度を示す係数を対応付けたテーブルを用いる構成とすればよい。各パラメータの重要度の合計値は１であるものとする。また、運転不能状態と覚醒状態といった複数種類のドライバ状態をそれぞれ判定する必要がある場合には、ドライバ状態の種類別に対応関係を用意しておく構成とすればよい。設定される重要度が他のパラメータに比べて高いパラメータほど、重みが大きいことになる。

また、自動化レベル３以上では、基本的にドライバは運転操作を行わず、車両信号をもとにしたドライバ状態の推定結果の信頼度が著しく低いと考えられるので、図５に示すように、自動化レベル３以上では、車両信号の重みをなしとすることが好ましい。

図５の例は、ドライバ画像及び車両信号に加え、生体信号も用いてドライバ状態を判定できるモードにおける例である。生体信号を用いずにドライバ状態を判定するモードでは、生体信号についての重要度を省略したテーブルを用いる構成とすればよい。この場合、テーブルにおいて、ドライバ画像についての重要度を示す係数と車両信号についての重要度を示す係数との合計値が常に１となるようにすればよい。

ドライバ状態判定部４０６は、各パラメータによるドライバ状態の推定結果と、自動化レベルに応じた各パラメータの重みとをもとに、ドライバ状態を判定する。一例としては、各パラメータから推定した個々のドライバ状態の段階に応じた数値に、各パラメータの重要度を示す係数をそれぞれ積算し、積算した値同士を足し合わせる。そして、得られた値の小数を四捨五入した数値が示すドライバ状態の段階を、ドライバ状態として判定する。ドライバ状態の段階に応じた数値は、例えば運転不能状態については、「運転可能」は０、「運転不能」は１とし、覚醒状態については、「覚醒」は０、「漫然」は１、「眠気」は２、「浅い睡眠」は３、「深い睡眠」は４とすればよい。

図５の例を用いて、ドライバ状態の判定の一例について説明する。例えば、自動化レベル２であって、車両信号による覚醒状態の推定結果は「覚醒」、ドライバ画像による覚醒状態の推定結果は「眠気」、身体信号による覚醒状態の推定結果は「眠気」であった場合、０×０．２＋２×０．５＋２×０．３＝１．６となる。この場合、１．６の小数を四捨五入した値は２であるので、ドライバ状態は「眠気」と判定することになる。

提示制御部４０７は、ドライバ状態判定部４０６で判定したドライバ状態が警告を要する状態である場合に、表示装置４３及び／又は音声出力装置４４から情報提示を行わせる。例えば、運転不能と判定した場合には、同乗者に向けてドライバの体調異常を知らせる情報提示を行わせる。また、判定した覚醒状態が、例えば「漫然状態」といった所定の覚醒度以下の場合に、ドライバの覚醒度を示す情報提示を行わせる構成としてもよい。ドライバの覚醒度を示す情報提示は、自動化レベル３以下といった自動化レベルが所定レベル以下の場合に限って行わせる構成とすることが好ましい。

刺激制御部４０８は、ドライバ状態判定部４０６で判定したドライバ状態が、ドライバ状態を改善させる刺激を必要とする状態である場合に、自動化レベル判定部４０５で判定した自動化レベルに応じたタイミング及び装置でドライバ状態を改善させる刺激を生じさせる。刺激制御部４０８での刺激の態様については後に詳述する。

要求送信部４０９は、接続中のウェアラブルデバイス２に対して、近距離通信機５を介して要求を送信する。要求の一例としては、ウェアラブルデバイス２の刺激部２５での刺激を開始させる要求等がある。

＜ドライバ状態判定関連処理＞
ここでは、図６のフローチャートを用いて、ＨＣＵ４０でのドライバ状態の判定に関連する処理（以下、ドライバ状態判定関連処理）の流れの一例について説明を行う。図６では、ウェアラブルデバイス２で測定した生体信号をＨＣＵ４０が取得できる場合であって、ドライバ状態として覚醒状態を判定する場合を例に挙げて説明を行う。図６のフローチャートは、車両ＨＶのイグニション電源がオンになった場合であって、且つ、ウェアラブルデバイス２が車室内に位置していることを連携状況検出部４０１で検出した場合に開始する構成とすればよい。

まず、ステップＳ１では、生体信号取得部４０２が、ウェアラブルデバイス２から近距離通信機５で受信する生体信号の取得を開始する。生体信号の取得を開始した後は、ウェアラブルデバイス２から近距離通信機５で受信する生体信号を逐次取得していくものとする。

ステップＳ２では、車両信号取得部４０４が、車速センサで検出した車速、舵角センサで検出した操舵角といった車両信号の取得を開始する。車両信号の取得を開始した後は、車速センサで検出した車速、舵角センサで検出した操舵角を逐次取得していくものとする。

ステップＳ３では、画像取得部４０３が、ドライバモニタカメラ４１から出力されるドライバ画像の取得を開始する。ドライバ画像の取得を開始した後は、ドライバモニタカメラ４１から出力されるドライバ画像を逐次取得していくものとする。なお、Ｓ１〜Ｓ３の処理は、順番が入れ替わった構成であってもよいし、並行して行う構成としてもよい。

ステップＳ４では、ドライバ状態判定部４０６でドライバ状態を判定するタイミングである場合（Ｓ４でＹＥＳ）には、ステップＳ５に移る。一方、ドライバ状態を判定するタイミングでない場合（Ｓ４でＮＯ）には、ステップＳ１４に移る。例えば、ドライバ状態判定部４０６でのドライバ状態の判定は、所定の時間間隔を空けて周期的に行われるものとし、ドライバ状態を判定する周期を、ドライバ状態を判定するタイミングとすればよい。

ステップＳ５では、自動化レベル判定部４０５が、車両ＨＶにおける運転操作の自動化レベルを判定する。ステップＳ６では、ドライバ状態判定部４０６が、例えば図５で示したテーブルをもとに、Ｓ５で判定した自動化レベルに応じた、車両信号、ドライバ画像、生体信号といったパラメータの重要度を設定する。

ステップＳ７では、生体信号取得部４０２で取得した生体信号、車両信号取得部４０４で取得した車両信号、画像取得部４０３で取得したドライバ画像といったパラメータと、Ｓ７で設定した各パラメータの重要度とをもとに、ドライバの覚醒状態を判定する。

ステップＳ８では、刺激制御部４０８が、Ｓ５で判定した自動化レベル及びＳ７で判定した覚醒状態をもとに、覚醒状態を改善させる刺激が必要か否か判断する。そして、刺激が必要と判断した場合（Ｓ８でＹＥＳ）には、ステップＳ９に移る。一方、刺激が不要と判断した場合（Ｓ８でＮＯ）には、ステップＳ１４に移る。一例として、Ｓ５で判定した自動化レベル及びＳ７で判定した覚醒状態をもとに、自動化レベルと覚醒状態との組み合わせごとに刺激の有無を対応付けた対応関係から、刺激が必要か否かを判断すればよい。

実施形態１の例では、図７に示すように、自動化レベル０〜２の場合には、覚醒度が「漫然」、「眠気」の場合に刺激が必要と判断する一方、覚醒度が「覚醒」、「浅い睡眠」、「深い睡眠」の場合には刺激が不要と判断すればよい。自動化レベル０〜２の場合において、覚醒度が「浅い睡眠」、「深い睡眠」の場合に刺激が不要と判断するのは、覚醒度が「浅い睡眠」、「深い睡眠」に達する前に刺激によって覚醒状態が改善される筈だからである。また、自動化レベル３以上の場合には、覚醒度が「漫然」、「眠気」、「浅い睡眠」、「深い睡眠」の場合に刺激が必要と判断する一方、覚醒度が「覚醒」の場合には刺激が不要と判断すればよい。自動化レベル３以上の場合において、覚醒度が「浅い睡眠」、「深い睡眠」の場合にも刺激が必要と判断するのは、走行中の運転操作が不要な状況においてドライバが仮眠を取ることが想定されるためである。

ステップＳ９では、刺激制御部４０８が、Ｓ５で判定した自動化レベル及びＳ７で判定した覚醒状態をもとに、刺激の態様を決定する。実施形態１では、決定する態様は、刺激の強さ、刺激を行う装置、刺激を開始するタイミングであるものとする。一例として、Ｓ５で判定した自動化レベル及びＳ７で判定した覚醒状態をもとに、自動化レベルと覚醒状態との組み合わせごとに刺激の強さ、刺激を行う装置、刺激を開始するタイミングを対応付けた対応関係から、刺激の態様を決定すればよい。

実施形態１の例では、図７に示すように、自動化レベル０〜２の場合には、覚醒度が「漫然」、「眠気」の場合に、刺激を行う装置を車両側ユニット３のアクチュエーション装置４５、刺激の開始タイミングを覚醒状態の判定直後と決定する。また、覚醒度が「漫然」の場合には、刺激の強さはやや強めと決定し、覚醒度が「眠気」の場合には、刺激の強さは強めと決定する。

一方、自動化レベル３以上の場合には、刺激を行う装置をウェアラブルデバイス２と決定する。自動化レベル３以上の場合において、覚醒度が「漫然」の場合には、刺激の強さは弱めと決定し、刺激の開始タイミングを、自動化レベル２以下に切替時若しくは目的地到着直前と決定する。目的地は、例えばナビゲーション装置において設定された目的地とすればよい。ここで言うところの直前とは、例えば１秒等とすればよい。覚醒度が「眠気」の場合には、刺激の強さはやや弱めと決定し、刺激の開始タイミングを、自動化レベル２以下に切替時若しくは目的地到着数秒前と決定する。覚醒度が「浅い睡眠」の場合には、刺激の強さはやや強めと決定し、刺激の開始タイミングを、自動化レベル２以下に切替時若しくは目的地到着数十秒前と決定する。覚醒度が「深い睡眠」の場合には、刺激の強さは強めと決定し、刺激の開始タイミングを、自動化レベル２以下に切替時若しくは目的地到着数分前と決定する。

自動化レベル３以上の場合に刺激の開始タイミングを覚醒状態の判定直後と決定しないのは、自動化レベル３以上ではドライバは基本的に運転操作を行わないので、直ちに覚醒状態を改善させる必要がないためである。よって、自動化レベル２以下に切り替わってドライバの運転操作が必要になったタイミング、若しくは目的地に到着したときに覚醒することが期待されるタイミングを、刺激の開始タイミングとする。

また、自動化レベル０〜２の場合には刺激を行う装置をアクチュエーション装置４５と決定するのに対して、自動化レベル３以上の場合には刺激を行う装置をウェアラブルデバイス２と決定するのは、自動化レベル３以上の場合にはドライバがステアリングを握っていない可能性が高く、アクチュエーション装置４５ではドライバに刺激を与えられない可能性が高いためである。よって、上述したように、自動化レベルが上がるのに応じて、運転操作時にドライバが触れる部材に設けられた装置で刺激を行わせる態様から、運転操作時以外にもドライバが触れる部材に設けられた装置で刺激を行わせる態様に切り替える構成とすることが好ましい。

ステップＳ１０では、Ｓ９で決定した刺激を開始するタイミングであった場合（Ｓ１０でＹＥＳ）には、ステップＳ１３に移る。一方、Ｓ９で決定した刺激を開始するタイミングでなかった場合（Ｓ１０でＮＯ）には、ステップＳ１１に移る。

ステップＳ１１では、Ｓ４と同様にして、ドライバ状態判定部４０６でドライバ状態を判定するタイミングである場合（Ｓ１１でＹＥＳ）には、ステップＳ５に移って、処理を繰り返す。一方、ドライバ状態を判定するタイミングでない場合（Ｓ１１でＮＯ）には、ステップＳ１２に移る。

ステップＳ１２では、ドライバ状態判定関連処理の終了タイミングであった場合（Ｓ１２でＹＥＳ）には、ドライバ状態判定関連処理を終了する。一方、ドライバ状態判定関連処理の終了タイミングでなかった場合（Ｓ１２でＮＯ）には、Ｓ１０に戻って処理を繰り返す。ドライバ状態判定関連処理の終了タイミングの一例としては、車両ＨＶのイグニッション電源がオフになったこと、ウェアラブルデバイス２が車室内に位置していることを連携状況検出部４０１で検出しなくなったこと等がある。

ステップＳ１３では、刺激制御部４０８が、Ｓ９で決定した刺激の強さでドライバに刺激を行わせる。Ｓ９で決定した刺激を行わせる装置が、アクチュエーション装置４５である場合には、刺激制御部４０８が、Ｓ９で決定した刺激の強さの刺激を発生させるようにアクチュエーション装置４５に指示を行う。指示を受けたアクチュエーション装置４５では、指示された強さの刺激をステアリングホイールで発生させることで、ステアリングホイールを握っているドライバの覚醒状態を改善させる。Ｓ９で決定した刺激を行わせる装置が、ウェアラブルデバイス２である場合には、刺激制御部４０８が、Ｓ９で決定した刺激の強さの刺激を発生させるように要求送信部４０９からウェアラブルデバイス２に向けて要求を送信させる。要求を受けたウェアラブルデバイス２では、主制御部２０が要求された強さの刺激を刺激部２５から発生させることで、ウェアラブルデバイス２を装着しているドライバの覚醒状態を改善させる。

ステップＳ１４では、ドライバ状態判定関連処理の終了タイミングであった場合（Ｓ１４でＹＥＳ）には、ドライバ状態判定関連処理を終了する。一方、ドライバ状態判定関連処理の終了タイミングでなかった場合（Ｓ１４でＮＯ）には、Ｓ４に戻って処理を繰り返す。

なお、車両ＨＶのイグニション電源がオンになっている場合であって、且つ、ウェアラブルデバイス２が車室内に位置していることを連携状況検出部４０１で検出できない場合には、生体信号を用いずにドライバ状態判定部４０６でドライバ状態を判定するモードに切り替え、ドライバ状態を判定する構成とすればよい。この場合であっても、身体信号を用いない点を除けば、図６で示したのと同様の処理を行う構成とすればよい。

図６のフローチャートでは、ドライバ状態判定部４０６で判定した覚醒状態についての提示制御部４０７による情報提示について述べなかったが、提示制御部４０７は、判定した覚醒状態を示す情報提示を行わせる構成としてもよいし、覚醒度が所定のレベル以下であった場合に限って情報提示を行わせる構成としてもよい。また、提示制御部４０７による情報提示を行わせない構成としてもよい。

＜実施形態１のまとめ＞
実施形態１の構成によれば、自動運転の実施時には、自動運転の不実施時に比べて、車両信号よりもドライバ画像、生体信号といったパラメータの重みを大きくしてドライバ状態を判定するので、ドライバの運転操作に起因して変化するものではない車両信号による実際のドライバ状態と判定結果との乖離を抑えることが可能になる。よって、自動運転の実施時であっても、ドライバ状態の判定精度の低下を抑えることが可能になる。

また、実施形態１の構成によれば、自動化レベルが上がるほど、ドライバ画像よりも生体信号の重みを大きく変更してドライバ状態を判定するので、ドライバ状態の判定精度の低下をさらに抑えることが可能になる。詳しくは、以下の通りである。自動化レベルが上がるのに従い、ドライバが運転操作を行う必要がなくなるため、ドライバが前方を注視する必要性も低下し、ドライバのよそ見が多くなっていくと考えられる。ドライバのよそ見が多くなるにつれて、ドライバ画像からの瞼、目等の検出が困難になり、例えばドライバ状態のうちの覚醒状態の判定が困難になる。これに対して、実施形態１の構成によれば、自動化レベルが上がるほど、ドライバ画像よりも生体信号の重みを大きく変更してドライバ状態を判定することで、ドライバ画像を用いることによる影響を抑え、ドライバ状態の判定精度の低下を抑えることができる。

さらに、実施形態１の構成によれば、自動化レベルに応じて、ドライバ状態を改善させる刺激の態様を変更させるので、自動化レベルに応じた刺激を行わせることが可能になる。詳しくは、以下の通りである。自動化レベル２以下の場合には、ドライバが運転操作を行う必要があるため、運転操作に支障がありそうなドライバ状態になった場合に、ドライバ状態に応じた強さの刺激をドライバに与える。一方、自動化レベル３以上になると、ドライバが基本的に運転操作を行う必要がないので、ドライバが仮眠をとる場合がある。しかしながら、自動化レベル２以下への切替時若しくは目的地到着時には、ドライバは覚醒している必要がある。そこで、ドライバ状態に応じた強さ及び開始タイミングで刺激を行わせることによって、覚醒が必要な時点までに、なるべく煩わしくなくドライバを覚醒させることを可能にしている。

（実施形態２）
また、自動化レベルに応じて、判定するドライバ状態を変更したり、追加したりする構成（以下、実施形態２）としてもよい。

以下、本発明の実施形態２について図面を用いて説明する。実施形態２のドライバ状態判定システム１は、ＨＣＵ４０の代わりにＨＣＵ４０ａを含む点を除けば、実施形態１のドライバ状態判定システム１と同様である。図８に示すように、ＨＣＵ４０ａは、連携状況検出部４０１、生体信号取得部４０２、画像取得部４０３、車両信号取得部４０４、自動化レベル判定部４０５、ドライバ状態判定部４０６ａ、提示制御部４０７、刺激制御部４０８、及び要求送信部４０９を備えている。ＨＣＵ４０ａは、ドライバ状態判定部４０６の代わりにドライバ状態判定部４０６ａを備える点を除けば実施形態１のＨＣＵ４０と同様である。

ドライバ状態判定部４０６ａは、自動化レベル判定部４０５で判定した自動化レベルに応じて、判定するドライバ状態の種類を変更したり、追加したりする点を除けば、実施形態１のドライバ状態判定部４０６と同様である。例えば、ドライバ状態判定部４０６ａは、自動化レベル２以下の場合には、睡眠の深さまでは判定しない一方、自動化レベル３以上の場合には、睡眠の深さまで判定する構成とすればよい。これは、自動化レベル３以上では、自動化レベル２以下とは異なり、ドライバが仮眠をとる可能性があるためである。

他にも、ドライバ状態判定部４０６ａが、自動化レベルが所定レベル以上の場合にはドライバ状態としてドライバの脇見状態を判定しないが、自動化レベルが所定レベル未満の場合には脇見状態を判定する等の構成としてもよい。ここで言うところの所定レベルは、自動化レベル２若しくは自動化レベル３とすればよい。これは、自動化レベルが下がることでドライバが安全確認を行う必要性が高まるためである。実施形態２の構成によれば、上述したように、自動化レベルに応じた、必要なドライバ状態の判定を行うことが可能になる。

（変形例１）
前述の実施形態では、自動運転を実施する際の自動化レベルに応じて、ドライバ状態の判定に用いるパラメータの重みを変更する構成を示したが、必ずしもこれに限らない。例えば、自動運転を実施する際のパラメータの重みは自動運転を実施する際の自動化レベルに関わらず一律とし、自動運転の実施不実施に応じてのみ、ドライバ状態の判定に用いるパラメータの重みを変更する構成としてもよい。

（変形例２）
前述の実施形態では、刺激制御部４０８が、刺激の態様として刺激の強さと刺激のタイミングとを変更する構成を示したが、必ずしもこれに限らない。例えば、刺激制御部４０８が、刺激の態様として刺激の強さと刺激のタイミングとのうちの刺激の強さのみを変更する構成としてもよいし、刺激の強さと刺激のタイミングとのうちの刺激のタイミングのみを変更する構成としてもよい。

（変形例３）
前述の実施形態では、アクチュエーション装置４５として、ステアリングホイールに設けられた振動子を例に挙げたが、必ずしもこれに限らない。例えば、ドライバに向けて冷風を吹き出す装置等であってもよいし、警報を出力する音声出力装置４４にアクチュエーション装置４５の機能を担わせる構成としてもよい。これらの構成を採用する場合には、自動化レベル３以上であってもドライバに刺激を行うことが可能と考えられるので、自動化レベル判定部４０５で判定された自動化レベルに応じた刺激の態様の変更は行わない構成とすればよい。

（変形例４）
前述の実施形態では、刺激制御部４０８が、ドライバ状態を改善させる刺激を行わせる構成を示したが、必ずしもこれに限らない。例えば、刺激制御部４０８を備えず、ドライバ状態を改善させる刺激を行わない構成としてもよい。

（変形例５）
前述の実施形態では、自動化レベル判定部４０５で判定した自動化レベルに関わらず、ドライバ状態の判定をＨＣＵ４０のドライバ状態判定部４０６で行う構成を示したが、必ずしもこれに限らない。例えば、自動化レベルに応じて、ドライバ状態の判定を行う装置を変更させる構成としてもよい。

例えば、自動化レベル２以下では、ドライバ状態判定部４０６でドライバ状態の判定を行う一方、自動化レベル３以上では、ウェアラブルデバイス２でドライバ状態の判定を行う構成とすればよい。この場合、ＨＣＵ４０の要求送信部４０９からドライバ状態の判定を行わせる要求をウェアラブルデバイス２に送信させ、ウェアラブルデバイス２でドライバ状態の判定を行わせる構成とすればよい。また、ウェアラブルデバイス２でドライバ状態の判定を行う場合には、計測関連部２１で計測した生体信号からドライバ状態を判定する構成とすればよい。そして、判定したドライバ状態に応じて、提示部２４から情報提示を行ったり、刺激部２５から刺激を行ったりすればよい。

（変形例６）
また、自動運転機能を１つでも実施している自動運転実施時には、車両信号の重みを０にする構成としてもよい。つまり、自動運転実施時には、ドライバ状態判定部４０６でのドライバ状態の判定に用いず、ドライバ画像、生体信号といった車両信号以外のパラメータを用いてドライバ状態を判定する構成としてもよい。これによれば、ドライバの運転操作に起因して変化するものではない車両信号を用いてドライバ状態を判定することがなくなる。よって、ドライバの運転操作に起因して変化するものではない車両信号を用いてドライバ状態を判定することによるドライバ状態の判定精度の低下を抑えることができる。

（変形例７）
他にも、自動化レベルに応じて、車両信号、ドライバ画像、生体信号のうちの１つのパラメータのみを用いてドライバ状態を判定する構成としてもよい。自動化レベルが上がるほど、ドライバ状態の判定における生体信号の信頼度が高くなる一方、車両信号の信頼度が低くなるので、自動化レベルが上がるのに応じて、車両信号、ドライバ画像、生体信号の順に、ドライバ状態の判定に用いるパラメータを切り替えていく構成としてもよい。

（変形例８）
前述の実施形態では、ドライバ状態判定部４０６でのドライバ状態の判定に、ウェアラブルデバイス２から受信した生体信号を用いる構成を示したが、必ずしもこれに限らない。例えば、ウェアラブルデバイス２以外の生体信号を計測する装置から受信した生体信号を用いる構成としてもよい。ウェアラブルデバイス２以外の生体信号を計測する装置の一例としては、運転席のシートに埋め込んだ電極によってドライバの生体信号を計測する装置、ステアリングホイールに埋め込んだ電極によってドライバの生体信号を計測する装置等がある。

（変形例９）
前述の実施形態では、ドライバ状態判定部４０６でのドライバ状態の判定に、ウェアラブルデバイス２から受信した生体信号とドライバモニタカメラ４１から取得したドライバ画像とのいずれも用いることができる構成を示したが、必ずしもこれに限らない。例えば、ドライバ状態判定部４０６でのドライバ状態の判定に、ウェアラブルデバイス２から受信した生体信号とドライバモニタカメラ４１から取得したドライバ画像とのうちのいずれか一方のみを用いる構成としてもよい。

（変形例１０）
また、ＨＣＵ４０は、ドライバモニタカメラ４１から取得したドライバ画像、車両ＨＶに搭載されたセンサで検出した車両信号、ウェアラブルデバイス２から近距離通信機５で受信した生体信号等のパラメータをサーバに送信し、サーバ側で判定させたドライバ状態を取得する構成としてもよい。

（変形例１１）
また、ウェアラブルデバイス２は、携帯電話機を介してＨＣＵ４０と情報のやり取りを行う構成としてもよい。

なお、本発明は、上述した実施形態及び変形例に限定されるものではなく、請求項に示した範囲で種々の変更が可能であり、異なる実施形態及び変形例にそれぞれ開示された技術的手段を適宜組み合わせて得られる実施形態についても本発明の技術的範囲に含まれる。

１ ドライバ状態判定システム、２ ウェアラブルデバイス、３ 車両側ユニット、５ 近距離通信機、９ 車両制御ＥＣＵ、２５ 刺激部、４０，４０ａ ＨＣＵ（ドライバ状態判定装置）、４５ アクチュエーション装置、４０２ 生体信号取得部（判定用情報取得部）、４０３ 画像取得部（判定用情報取得部）、４０４ 車両信号取得部、４０６，４０６ａ 状態判定部（ドライバ状態判定部）、４０８ 刺激制御部

Claims (9)

1. 加速、制動、及び操舵の少なくともいずれかを自動で制御する自動運転を行うことができる車両で用いられ、
   前記自動運転の実施不実施は切り替えられるものであり、
   前記車両のドライバの状態であるドライバ状態を判定できる、前記車両の車両信号を取得する車両信号取得部（４０４）と、
   前記ドライバ状態を判定できる情報として前記車両信号以外の情報である判定用情報を取得する判定用情報取得部（４０２，４０３）と、
   前記車両信号取得部で取得した前記車両信号と前記判定用情報取得部で取得した前記判定用情報との少なくともいずれかを用いて前記ドライバ状態を判定する状態判定部（４０６，４０６ａ）とを備え、
   前記状態判定部は、前記自動運転の不実施時には、前記車両信号を用いて前記ドライバ状態を判定する一方、前記自動運転の実施時には、前記車両信号を用いずに前記ドライバ状態を判定するドライバ状態判定装置。
2. 加速、制動、及び操舵の少なくともいずれかを自動で制御する自動運転を行うことができる車両で用いられ、
   前記自動運転の実施不実施は切り替えられるものであり、
   前記車両のドライバの状態であるドライバ状態を判定できる、前記車両の車両信号を取得する車両信号取得部（４０４）と、
   前記ドライバ状態を判定できる情報として前記車両信号以外の情報である判定用情報を取得する判定用情報取得部（４０２，４０３）と、
   前記車両信号取得部で取得した前記車両信号と前記判定用情報取得部で取得した前記判定用情報との少なくともいずれかを用いて前記ドライバ状態を判定する状態判定部（４０６，４０６ａ）とを備え、
   前記自動運転は、自動化のレベルを複数段階に切り替えられるものであり、
   前記状態判定部は、前記自動運転の実施時には、前記自動運転の不実施時に比べて、前記車両信号よりも前記判定用情報の重みを大きくして前記ドライバ状態を判定し、前記自動運転の自動化のレベルが上がるほど、前記車両信号よりも前記判定用情報の重みを大きくして前記ドライバ状態を判定するドライバ状態判定装置。
3. 請求項２において、
   前記状態判定部（４０６ａ）は、判定する前記ドライバ状態の変更及び追加の少なくともいずれかを行うことができるものであって、前記自動運転の自動化のレベルに応じて、判定する前記ドライバ状態の変更及び追加の少なくともいずれかを行うドライバ状態判定装置。
4. 請求項２又は３において、
   前記ドライバ状態を改善させる刺激を前記ドライバに与えさせる刺激制御部（４０８）をさらに備え
   前記刺激制御部は、前記自動運転の自動化のレベルに応じて、前記ドライバ状態を改善させる刺激を前記ドライバに与えさせる態様を変更するドライバ状態判定装置。
5. 請求項４において、
   前記刺激制御部は、前記自動運転の自動化のレベルに応じて、前記ドライバ状態を改善させる刺激の強さを変更するドライバ状態判定装置。
6. 請求項４又は５において、
   前記刺激制御部は、前記自動運転の自動化のレベルに応じて、前記ドライバ状態を改善させる刺激を開始させるタイミングを変更するドライバ状態判定装置。
7. 請求項２〜６のいずれか１項において、
   前記判定用情報取得部は、前記ドライバ状態を判定できる情報として前記ドライバの生体信号を取得する生体信号取得部（４０２）と、前記ドライバ状態を判定できる情報として前記ドライバを撮像した撮像画像の情報を取得する画像取得部（４０３）との少なくともいずれかを含むドライバ状態判定装置。
8. 請求項７において、
   前記判定用情報取得部は、前記生体信号取得部と前記画像取得部とを含み、
   前記状態判定部は、前記自動運転の自動化のレベルに応じて、前記生体信号と前記撮像画像の情報との重みを変更して前記ドライバ状態を判定するドライバ状態判定装置。
9. 請求項８において、
   前記状態判定部は、前記自動運転の自動化のレベルが上がるほど、前記撮像画像の情報よりも前記生体信号の重みを大きく変更して前記ドライバ状態を判定するドライバ状態判定装置。

Images