知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2025017723
(43)【公開日】2025-02-06
(54)【発明の名称】ドライバ状態判定装置
(51)【国際特許分類】
G08B 21/06 20060101AFI20250130BHJP
B60Q 1/04 20060101ALI20250130BHJP
G08B 21/00 20060101ALI20250130BHJP
G08B 25/04 20060101ALI20250130BHJP
G08B 25/00 20060101ALI20250130BHJP
【ＦＩ】
G08B21/06
B60Q1/04 Z
G08B21/00 U
G08B25/04 K
G08B25/00 510M
【審査請求】未請求
【請求項の数】5
【出願形態】ＯＬ
(21)【出願番号】P 2023120909
(22)【出願日】2023-07-25
(71)【出願人】
【識別番号】000003137
【氏名又は名称】マツダ株式会社
(74)【代理人】
【識別番号】110001427
【氏名又は名称】弁理士法人前田特許事務所
(72)【発明者】
【氏名】前▲濱▼ 孝太
(72)【発明者】
【氏名】中井川 隼也
(72)【発明者】
【氏名】尾▲崎▼ 昂
(72)【発明者】
【氏名】中畑 洋一朗
(72)【発明者】
【氏名】山本 直樹
【テーマコード（参考）】
3K339
5C086
5C087
【Ｆターム（参考）】
3K339AA02
3K339BA30
3K339CA01
3K339JA01
3K339JA11
3K339KA18
3K339MA01
3K339MA05
3K339MC76
5C086AA23
5C086BA22
5C086CA28
5C086CB36
5C086DA08
5C086DA33
5C086FA02
5C086FA12
5C086FA18
5C087AA02
5C087AA12
5C087AA25
5C087AA32
5C087BB03
5C087DD03
5C087DD13
5C087EE07
5C087EE14
5C087FF01
5C087FF04
5C087GG02
5C087GG08
5C087GG66
(57)【要約】
【課題】車両のコストアップを招くことなく、ドライバの状態をより正確に判定する。
【解決手段】ドライバ状態判定装置１は、車外の光を検出する陽光センサ３２と、ドライバの顔画像を撮像する車載カメラ４と、通信経路５を介して陽光センサ３２及び車載カメラ４と接続されたＥＣＵ１０と、を備える。ＥＣＵ１０は、車載カメラ４の撮像結果に基づいてドライバの閉眼を判定し、その判定結果に基づいて、車室内への警告発令又は車両１００の自動停車を指令する第１処理を実行し、陽光センサ３２の出力値が第１閾値を超えた場合に満足される第１条件と、現時点における出力値から該出力値の直近の移動平均を減算した値が第２閾値を超えた場合に満足される第２条件と、をそれぞれ判定し、第１条件及び第２条件が双方とも満足された場合に、第１処理の実行を遅延又は抑制する。
【選択図】図７
【解決手段】ドライバ状態判定装置１は、車外の光を検出する陽光センサ３２と、ドライバの顔画像を撮像する車載カメラ４と、通信経路５を介して陽光センサ３２及び車載カメラ４と接続されたＥＣＵ１０と、を備える。ＥＣＵ１０は、車載カメラ４の撮像結果に基づいてドライバの閉眼を判定し、その判定結果に基づいて、車室内への警告発令又は車両１００の自動停車を指令する第１処理を実行し、陽光センサ３２の出力値が第１閾値を超えた場合に満足される第１条件と、現時点における出力値から該出力値の直近の移動平均を減算した値が第２閾値を超えた場合に満足される第２条件と、をそれぞれ判定し、第１条件及び第２条件が双方とも満足された場合に、第１処理の実行を遅延又は抑制する。
【選択図】図７
【特許請求の範囲】
【請求項1】
車両を操縦するドライバの状態を判定するドライバ状態判定装置であって、
車外の光を検出するとともに、該光が明るくなるほど大きくなるよう設定された値を有する信号を出力する車載センサと、
前記ドライバの顔画像を撮像する車載カメラと、
通信経路を介して前記車載センサ及び前記車載カメラと接続されたコントローラと、を備え、
前記コントローラは、
前記車載カメラの撮像結果に基づいて、前記ドライバの閉眼を判定し、
前記閉眼の判定結果に基づいて、車室内への警告発令又は前記車両の自動停車を指令する第１処理を実行し、
前記車載センサの出力値が第１閾値を超えた場合又は該第１閾値以上の場合に満足される第１条件と、現時点における前記出力値から該出力値の直近の移動平均を減算した値が第２閾値を超えた場合又は該第２閾値以上の場合に満足される第２条件と、をそれぞれ判定し、
前記第１条件及び前記第２条件が双方とも満足された場合に、前記第１処理の実行を遅延又は抑制する
ことを特徴とするドライバ状態判定装置。
車外の光を検出するとともに、該光が明るくなるほど大きくなるよう設定された値を有する信号を出力する車載センサと、
前記ドライバの顔画像を撮像する車載カメラと、
通信経路を介して前記車載センサ及び前記車載カメラと接続されたコントローラと、を備え、
前記コントローラは、
前記車載カメラの撮像結果に基づいて、前記ドライバの閉眼を判定し、
前記閉眼の判定結果に基づいて、車室内への警告発令又は前記車両の自動停車を指令する第１処理を実行し、
前記車載センサの出力値が第１閾値を超えた場合又は該第１閾値以上の場合に満足される第１条件と、現時点における前記出力値から該出力値の直近の移動平均を減算した値が第２閾値を超えた場合又は該第２閾値以上の場合に満足される第２条件と、をそれぞれ判定し、
前記第１条件及び前記第２条件が双方とも満足された場合に、前記第１処理の実行を遅延又は抑制する
ことを特徴とするドライバ状態判定装置。
【請求項2】
請求項１に記載されたドライバ状態判定装置において、
前記車載センサは、車外から入射する光の照度を検出する照度センサであり、
前記コントローラは、前記照度が所定未満の場合に、前記車両のヘッドランプを自動的に点灯させる
ことを特徴とするドライバ状態判定装置。
前記車載センサは、車外から入射する光の照度を検出する照度センサであり、
前記コントローラは、前記照度が所定未満の場合に、前記車両のヘッドランプを自動的に点灯させる
ことを特徴とするドライバ状態判定装置。
【請求項3】
請求項１に記載されたドライバ状態判定装置において、
前記車載センサは、車外から入射する光の照度を検出する照度センサであり、
前記コントローラは、
前記照度センサの検出信号に基づいて雨天であるか否かを判定し、
雨天であると判定した場合には、前記車両のワイパーを自動的に作動させる
ことを特徴とするドライバ状態判定装置。
前記車載センサは、車外から入射する光の照度を検出する照度センサであり、
前記コントローラは、
前記照度センサの検出信号に基づいて雨天であるか否かを判定し、
雨天であると判定した場合には、前記車両のワイパーを自動的に作動させる
ことを特徴とするドライバ状態判定装置。
【請求項4】
請求項１に記載されたドライバ状態判定装置において、
前記コントローラは、
前記閉眼の継続時間をカウントするとともに、該継続時間が所定期間以上の場合に前記第１処理を実行し、
前記第１条件及び前記第２条件が双方とも満足された場合に、前記継続時間のカウントをリセットする
ことを特徴とするドライバ状態判定装置。
前記コントローラは、
前記閉眼の継続時間をカウントするとともに、該継続時間が所定期間以上の場合に前記第１処理を実行し、
前記第１条件及び前記第２条件が双方とも満足された場合に、前記継続時間のカウントをリセットする
ことを特徴とするドライバ状態判定装置。
【請求項5】
請求項１に記載されたドライバ状態判定装置において、
前記第１閾値は、前記第２閾値よりも大きい
ことを特徴とするドライバ状態判定装置。
前記第１閾値は、前記第２閾値よりも大きい
ことを特徴とするドライバ状態判定装置。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、ドライバ状態判定装置に関する。
【背景技術】
【0002】
特許文献１には、居眠り運転警報装置が開示されている。この装置は、眼の開度検出手段と、開閉眼判定基準値補正手段と、開閉状態判定手段と、覚醒度判定手段と、警報手段と、を備えている。眼の開度検出手段は、顔画像に基づいて、眼の開度を検出する。開閉眼判定基準値補正手段は、運転者が眩しさを感じる状態を推定し、開閉眼判定に用いられる基準値を補正する。開閉状態判定手段は、眼の開度と補正後の基準値に基づいて、眼の開閉状態を判定する。覚醒度判定手段は、開閉状態判定手段による判定結果に基づいて、眼の開閉状態の変化から覚醒度を判定する。警報手段は、覚醒度判定手段による判定結果に基づいて、警報を発する。
【0003】
前記特許文献１によれば、開閉眼判定基準値補正手段は、運転者の眼の位置の濃度情報に基づいて、該運転者が眩しさを感じる状態を推定する。その推定結果に基づいて前記基準値を補正することで、警報の精度向上を図るようになっている。
【0004】
また、特許文献２には、車両用監視装置が開示されている。この車両用監視装置は、運転状態測定部と、警報判定部と、日照方向取得部と、を備えている。運転状態判定部は、運転者の画像に基づいて、該運転者の開眼度を含んだ複数の運転状態を測定する。警報判定部は、開眼度に基づいて、警報装置を作動させるか否かを判定する。日照方向判定部は、日時、位置情報及び日照方向を対応付けて格納する日照方向データベースを参照して、日照方向を取得する。
【0005】
前記特許文献２によれば、前記警報判定部は、車両の進行方向と日照方向とが所定の関係を満たす場合、運転状態判定部に開眼度の検出処理を再実行させる。日照方向に応じて検出処理を再実行させることで、運転者の顔に直射日光が当たる場合を考慮することができ、居眠り運転、脇見運転等の誤判定を抑制することができる。
【0006】
また、特許文献３には、照度センサによって、乗員の顔面照度を検出することが開示されている。この照度センサは、環境照度を測定して出力するものであり、車両のライト自動点灯装置にも用いられるようになっている。
【先行技術文献】
【特許文献】
【0007】
【特許文献1】特開２０００－１９８３６９号公報
【特許文献2】特開２０００－４７０８６号公報
【特許文献3】特開平９－５３９１７号公報
【発明の概要】
【発明が解決しようとする課題】
【0008】
本願発明者らは、ドライバの閉眼を判定することで、そのドライバが正常であるか否か（例えば、ドライバが居眠りしているか否か）を判定し、正常でない場合には警報又は自動停車を行うような仕組みを検討した。
【0009】
ところが、例えば西日等の陽光が差し込んだ場合には、そのドライバが正常であったとしても、意図せずして閉眼に至る可能性がある。警報又は自動停車をより適切に行うためには、そうした状況にあることを判定する必要がある。
【0010】
意図せぬ閉眼を判定するためには、例えば特許文献１及び２に記載された手法が考えられる。しかしながら、それら公知の手法は、眼の位置を精密に解析するためのハードの新設、日照方向の判定に特化したプログラムの導入等を必要とするため、車両のコストダウンには不都合である。
【0011】
そこで、例えば特許文献３に記載されているように、車両のライトを自動的に点灯させるための照度センサを用いることが考えられる。しかしながら、自動点灯に用いられるような照度センサは、その明るい側の分解能が、暗い側の分解能ほど優れていない。
【0012】
そのため、本願発明者らの実験結果によれば、前記特許文献３に記載されているような照度センサを用いた場合、ドライバが眩しさを感じないような曇り空と、眩しさのあまり閉眼してしまうような状況と、を明確に区別できないことが新たに分かった。このことは、ドライバの状態を正確に判定するには不都合である。
【0013】
本開示は、かかる点に鑑みてなされたものであり、その目的とするところは、車両のコストアップを招くことなく、ドライバの状態をより正確に判定することにある。
【課題を解決するための手段】
【0014】
本開示の第１の態様は、車両を操縦するドライバの状態を判定するドライバ状態判定装置に係る。このドライバ状態判定装置は、車外の光を検出するとともに、該光が明るくなるほど大きくなるよう設定された値を有する信号を出力する車載センサと、前記ドライバの顔画像を撮像する車載カメラと、通信経路を介して前記車載センサ及び前記車載カメラと接続されたコントローラと、を備え、前記コントローラは、前記車載カメラの撮像結果に基づいて、前記ドライバの閉眼を判定し、前記閉眼の判定結果に基づいて、車室内への警告発令又は前記車両の自動停車を指令する第１処理を実行し、前記車載センサの出力値が第１閾値を超えた場合又は該第１閾値以上の場合に満足される第１条件と、現時点における前記出力値から該出力値の直近の移動平均を減算した値が第２閾値を超えた場合又は該２閾値以上の場合に満足される第２条件と、をそれぞれ判定し、前記第１条件及び前記第２条件が双方とも満足された場合に、前記第１処理の実行を遅延又は抑制する。
【0015】
本願発明者らによれば、例えば、トンネルから出た直後に西日が差し込んだ場合のように、車内に差し込む明るさが短期間のうちに大きく増加すると、眼の明順応が追いつかない可能性がある。その場合、ドライバに意図せぬ閉眼を招き得ることが新たに判った。
【0016】
明順応に係る判定を行うためには、明るい側における光量の変化を、細やかに検出することが求められる。しかしながら、いわゆるオートライト制御に用いられるような一般的な車載センサは、明るい側の分解能が、暗い側ほど優れていない。ゆえに、そうした車載センサは、従来の知見だけでは、明順応に係る判定に用いるには不都合であった。
【0017】
こうした課題に対し、本願発明者らは、光量の増加を細やかに判定するために、車載センサの出力値それ自体に加えて、その直近の移動平均を用いることを新たに着想した。
【0018】
実際のところ、車載センサの出力値が短期間のうちに大きく増加したとき、その直近の移動平均は、出力値よりも緩やかに増加することになる。移動平均は、出力値と同様の値に向かって変化するものの、その変化が完了するタイミングは、出力値よりも遅れることになる。
【0019】
すなわち、車載センサの出力値が短期間で増加したとき、その出力値から移動平均を減算した値は、正の値となりつつ、一時的に増加することになる。
【0020】
そこで、本願発明者らは、以下に挙げる２つの条件（Ａ）及び（Ｂ）が双方とも満足された場合に、明順応に起因した閉眼を招き得ると考えた。
【0021】
・出力値＞第１閾値 …（Ａ）
・出力値－移動平均＞第２閾値 …（Ｂ）
これらの条件（Ａ）及び（Ｂ）は、それぞれ、前記第１条件及び第２条件に他ならない。まず、前記第１条件が満足されると、ドライバが、眩しさを感じ得る環境下にあると判断することができる。さらに、前記第２条件が満足されると、車内に差し込む明るさが、短期間のうちに、ドライバが眩しさを感じ得るほど大きく増加したものと判断することができる。
・出力値－移動平均＞第２閾値 …（Ｂ）
これらの条件（Ａ）及び（Ｂ）は、それぞれ、前記第１条件及び第２条件に他ならない。まず、前記第１条件が満足されると、ドライバが、眩しさを感じ得る環境下にあると判断することができる。さらに、前記第２条件が満足されると、車内に差し込む明るさが、短期間のうちに、ドライバが眩しさを感じ得るほど大きく増加したものと判断することができる。
【0022】
したがって、前記第１条件及び第２条件が双方とも満足された場合、眼の明順応が追いつかず、ドライバに意図せぬ閉眼を招き得る状況にあると判断することが可能になる。眠気等の要因ではなく、眩しさのあまり意図せずして閉眼した場合、そのドライバは正常であると判定することができる。
【0023】
そして、前記第１の態様によると、前記コントローラは、第１及び第２条件が双方とも満足された場合、つまり、ドライバが正常であると判定された場合、第１処理の実行を遅延又は抑制する。これにより、ドライバ状態の誤検知に起因した第１処理の実行を、遅延又抑制することが可能になる。
【0024】
そして、前記第１の態様は、比較的一般的な車載センサを用いて実現することができる。また、第１及び第２条件の判定は、高度な日照プログラムを用いずとも実現することができる。ゆえに、車両のコストアップを招くことなく、ドライバの状態をより正確に判定することができる。
【0025】
また、本開示の第２の態様によれば、前記車載センサは、車外から入射する光の照度を検出する照度センサであり、前記コントローラは、前記照度が所定未満の場合に、前記車両のヘッドランプを自動的に点灯させる、としてもよい。
【0026】
前記第２の態様によると、前記車載センサは、ヘッドランプの自動点灯に使用可能な照度センサ、いわゆるオートライトセンサである。その照度センサに、第１及び第２条件を判定するためのセンサを兼用させることで、車両のコストアップを抑制する上で有利となる。
【0027】
また、本開示の第３の態様によれば、前記車載センサは、車外から入射する光の照度を検出する照度センサであり、前記コントローラは、前記照度センサの検出信号に基づいて雨天であるか否かを判定し、雨天であると判定した場合には、前記車両のワイパーを自動的に作動させる、としてもよい。
【0028】
前記第３の態様によると、前記車載センサは、ワイパーの自動動作に使用可能な照度センサ、いわゆるレインセンサである。その照度センサに、第１及び第２条件を判定するためのセンサを兼用させることで、車両のコストアップを抑制する上で有利となる。
【0029】
また、本開示の第４の態様によれば、前記コントローラは、前記閉眼の継続時間をカウントするとともに、該継続時間が所定期間以上の場合に前記第１処理を実行し、前記第１条件及び前記第２条件が双方とも満足された場合に、前記継続時間のカウントをリセットする、としてもよい。
【0030】
前記第４の態様によると、コントローラは、第１条件及び第２条件が双方とも満足された場合に、継続時間のカウントをリセットする。継続時間のカウントをリセットすることで、前記第１処理を実行させないようにすることができる。これにより、ドライバ状態の誤検知に起因した第１処理の実行を、遅延又抑制する上で有利になる。
【0031】
また、本開示の第５の態様によれば、前記第１閾値は、前記第２閾値よりも大きい、としてもよい。
【0032】
前記第５の態様によれば、第１閾値を相対的に大きく設定することで、ドライバが眩しさを感じ得る環境下にあることを、より確実に判定することが可能になる。このことは、ドライバ状態のより正確な判定に資する。
【発明の効果】
【0033】
以上説明したように、本開示によれば、車両のコストアップを招くことなく、ドライバの状態をより正確に判定することができる。
【図面の簡単な説明】
【0034】
【発明を実施するための形態】
【0035】
以下、本開示の実施形態について詳細に説明する。なお、以下の説明は例示である。
【0036】
図１は、本実施形態に係るドライバ状態判定装置１を備える車両１００を例示する概略図である。図２は、ドライバ状態判定装置１の構成を例示するブロック図である。また、図３は陽光センサ３２のレイアウトを例示する斜視図であり、図４は陽光センサ３２の分解能を例示するグラフである。
【0037】
なお、以下の説明では、車両１００に搭乗しているドライバから見た前、後、左、上及び下を、それぞれ単に前、後、左、上及び下という。これら前後方向、左右方向及び上下方向の定義は、説明を簡単にするための便宜上の定義に過ぎない。
【0038】
＜車両１００の全体構成＞
図１に示す車両１００は、４輪の自動車である。車両１００は、エンジン、モータ等の動力源１００ａを備えている。車両１００は、動力源１００ａが車輪を駆動することによって走行する。車両１００は、ガソリン車であってもよいし、ハイブリッド車であってもよいし、電気自動車であってもよいし、燃料電池自動車であってもよい。動力源１００ａの種類は、特に限定されない。
図１に示す車両１００は、４輪の自動車である。車両１００は、エンジン、モータ等の動力源１００ａを備えている。車両１００は、動力源１００ａが車輪を駆動することによって走行する。車両１００は、ガソリン車であってもよいし、ハイブリッド車であってもよいし、電気自動車であってもよいし、燃料電池自動車であってもよい。動力源１００ａの種類は、特に限定されない。
【0039】
車両１００には、ドライバ状態判定装置１が搭載されている。このドライバ状態判定装置１は、車両１００を操縦するドライバの状態を判定するための装置である。図２に示すように、本実施形態に係るドライバ状態判定装置１は、車両機器２と、車載センサ３と、車載カメラ４と、通信経路５と、ＥＣＵ（Electrical Control Unit）１０と、を備えている。ドライバ状態判定装置１は、判定したドライバの状態に基づいて、車両機器２及びアクチュエータ６を作動させることもできる。
【0040】
車両機器２は、ヘッドランプ２１と、ワイパー２２と、非常点滅表示灯２３と、ディスプレイ２４と、ホーン２５と、によって構成されている。これらの車両機器２は、通信経路５を介してＥＣＵ１０に接続されている。通信経路５は、各車両機器２と、ＥＣＵ１０との間で信号を送受させる。通信経路５における通信プロトコロルには、例えばＣＡＮ（Controller Area Network）を採用してもよい。
【0041】
車載センサ３は、ハンドルセンサ３１と、陽光センサ３２と、によって構成されている。これらの車載センサ３は、通信経路５を介してＥＣＵ１０に接続されている。通信経路５は、各車載センサ３と、ＥＣＵ１０との間で信号を送受させる。
【0042】
ハンドルセンサ３１は、車両１００のステアリングに内蔵されている。ハンドルセンサ３１は、例えば、静電容量方式のタッチセンサである。ハンドルセンサ３１は、ドライバによってステアリングが把持されているか否かを検出する。ハンドルセンサ３１の検出信号は、通信経路５を介してＥＣＵ１０に入力される。
【0043】
陽光センサ３２は、車両１００の外部（車外）の光を検出する。陽光センサ３２は、検出した光が明るくなるほど大きくなるように設定された値を有する信号を出力する。言い換えると、陽光センサ３２の出力値は、車外の光が明るくなるほど大きくなる。陽光センサ３２の検出信号は、通信経路５を介してＥＣＵ１０に入力される。
【0044】
具体的に、本実施形態に係る陽光センサ３２は、車外から入射する光の照度を検出する照度センサである。照度センサとしての陽光センサ３２は、図３に示すように、ウインドシールド１００ｂの後方の車内に配置されている。陽光センサ３２は、車両１００の前方乃至側方から車内に差し込んだ光の照度を検出する。陽光センサ３２の検出信号は、所定周期毎にＥＣＵ１０に入力される。本実施形態に係る陽光センサ３２は、例えば１分間あたり５個の周期で、その検出信号をＥＣＵ１０に入力する。
【0045】
詳しくは、陽光センサ３２の検出信号は、１０ｂｉｔの値、つまり、０から１０２４までの値に変化し得る。この検出信号の値は、検出した光の明るさに対し、例えば正の相関を有している。陽光センサ３２に照度センサを用いた場合、検出信号の値は、検出した照度が大きくなるほど大きくなる。以下、陽光センサ３２の検出信号の値を、単に「陽光センサ３２の信号値」又は「陽光センサ３２の出力値」ともいう。
【0046】
さらに詳しくは、陽光センサ３２の分解能は、明るい側（高照度側）と、暗い側（低照度側）と、で相違している。なお、ここでいう分解能とは、陽光センサ３２の信号値の変化量に対する照度の変化量（例えば、１ＬＳＢあたりの照度の変化量）をいう。分解能は、受光感度と呼ぶこともできる。
【0047】
本実施形態に係る陽光センサ３２は、暗い側の分解能が、明るい側の分解能よりも小さい。すなわち、陽光センサ３２は、夜間、曇り、雨天時等の走行に際しては、照度の変化を相対的に細やかに捉えることができる。一方、陽光センサ３２は、日中の晴天時等における走行に際しては、照度の変化を相対的に粗く捉えるようになっている。
【0048】
【0049】
図４に示すように、本実施形態に係る陽光センサ３２は、３種類の分解能［Ｌｘ／ＬＳＢ］を有している。それら分解能は、前記出力値が小さいものから順に、徐々に大きくなるように設定されている。言い換えると、出力値が小さい側、つまり暗い側の分解能は、出力値が大きい側、つまり明るい側の分解能よりも相対的に小さくなるように設定されている。具体的に、３種類の分解能は、第１領域Ｒ１、第２領域Ｒ２及び第３領域Ｒ３の順番で大きくなる。第１領域Ｒ１は、出力値の下限値を含んでいる。第３領域Ｒ３は、出力値の上限値を含んでいる。第２領域Ｒ２は、第１領域Ｒ１及び第３領域Ｒ３の間に位置している。
【0050】
暗い側の分解能を相対的に小さくすることで、陽光センサ３２は、ヘッドランプ２１を自動的に点灯させる制御、いわゆるオートライト機能に適したものとなる。陽光センサ３２は、オートライトセンサと呼ぶこともできる。
【0051】
また、陽光センサ３２は、ウインドシールド１００ｂに付着した雨滴からの反射光等を測定するレインセンサを兼用してもよい。レインセンサを兼用する場合、陽光センサ３２は、ワイパー２２自動的に作動させる機能、いわゆるオートワイパー機能に用いてもよい。オートワイパー機能については後述する。
【0052】
なお、陽光センサ３２は、照度センサには限定されない。陽光センサ３２は、光の輝度検出する輝度センサであってもよい。陽光センサ３２は、光の光度、光束等、光量に関連した物理量を検出するセンサであってもよいし、光量自身を検出するセンサであってもよい。例えば、陽光センサ３２に輝度センサを用いた場合、その出力値は、検出した輝度が大きくなるほど大きくなる。同様に、陽光センサ３２に光度センサを用いた場合、その出力値は、検出した光度が大きくなるほど大きくなる。
【0053】
車載カメラ４は、ドライバの顔画像を撮像する。車載カメラ４は、通信経路５を介してＥＣＵ１０に接続されている。車載カメラ４によって撮像された顔画像に対応した電気信号は、通信経路５を介してＥＣＵ１０に入力される。
【0054】
詳しくは、車載カメラ４は、車内に配置されている。例えば、車載カメラ４は、車両１００のダッシュボード付近に位置するディスプレイ２４に内蔵されている。車載カメラ４は、ドライバーモニタリングカメラと呼ぶこともできる。
【0055】
さらに詳しくは、車載カメラ４は、近赤外領域の感度を高めたカメラセンサと、ドライバを照らすための近赤外光を発光するＬＥＤと、を有している。車載カメラ４は、ドライバを含んだ車内の状況を、カメラセンサによって撮像する。車載カメラ４によって撮像される車内の状況には、ドライバの顔画像に加えて、例えばドライバの運転姿勢が含まれる。
【0056】
ＥＣＵ１０は、いわゆる電子制御ユニットである。ＥＣＵ１０は、本実施形態におけるコントローラを構成している。コントローラとしてのＥＣＵ１０は、通信経路５を介して車両機器２、車載センサ３及び車載カメラ４と接続されている。
【0057】
具体的に、本実施形態に係るＥＣＵ１０は、プロセッサと、メモリと、入出力バスと、を有するマイクロコンピュータである。また、ＥＣＵ１０は、複数の電子制御ユニットによって構成してもよい。その場合、複数の電子制御ユニットは、それぞれ、プロセッサ、メモリ、入出力バス等を有することになる。
【0058】
ＥＣＵ１０は、通信経路５を介して車両１００のアクチュエータ６とも接続されている。車両１００のアクチュエータ６には、例えば、車両１００のパワーステアリングシステムと、パーキングブレーキと、動力源１００ａと、動力源１００ａの補機と、の１つ以上の組み合わせが含まれ得る。
【0059】
＜ＥＣＵ１０の詳細＞
図２に示すように、ＥＣＵ１０は、オートライト部１１と、オートワイパー部１２と、画像解析部１３と、異常判定部１４と、第１処理部１５と、第２処理部１６と、を備えている。
図２に示すように、ＥＣＵ１０は、オートライト部１１と、オートワイパー部１２と、画像解析部１３と、異常判定部１４と、第１処理部１５と、第２処理部１６と、を備えている。
【0060】
（オートライト部１１）
オートライト部１１は、陽光センサ３２の検出信号に基づいて、オートライト制御を実行する。オートライト制御とは、周囲の明るさに応じて、ヘッドランプ２１、及び他のランプ類を自動的に点灯させる制御をいう。他のランプ類とは、車幅灯、尾灯及び番号灯の少なくとも１つをいう。このオートライト制御によって実現される機能が、前述のオートライト機能に相当する。
オートライト部１１は、陽光センサ３２の検出信号に基づいて、オートライト制御を実行する。オートライト制御とは、周囲の明るさに応じて、ヘッドランプ２１、及び他のランプ類を自動的に点灯させる制御をいう。他のランプ類とは、車幅灯、尾灯及び番号灯の少なくとも１つをいう。このオートライト制御によって実現される機能が、前述のオートライト機能に相当する。
【0061】
本実施形態に係るオートライト部１１は、陽光センサ３２の検出信号を読み込むとともに、その検出信号に対応した照度が所定未満の場合に、車両１００のヘッドランプ２１及び他のライト類を自動的に点灯させる。また、オートライト部１１は、陽光センサ３２の検出信号を読み込むとともに、その検出信号に対応した照度が所定以上の場合に、車両１００のヘッドランプ２１及び他のライト類を消灯させる。
【0062】
なお、オートライト制御は、ドライバの操作に基づいて、そのオンオフ（オートライト制御を行うか否か）を適宜切り替えることができる。また、オートライト部１１は、そもそも必須ではない。
【0063】
（オートワイパー部１２）
オートワイパー部１２は、陽光センサ３２の検出信号に基づいて、オートワイパー制御を実行する。オートワイパー制御とは、雨天時に、ワイパー２２を自動的に作動させる制御をいう。このオートワイパー制御によって実現される機能が、前述のオートワイパー機能に相当する。
オートワイパー部１２は、陽光センサ３２の検出信号に基づいて、オートワイパー制御を実行する。オートワイパー制御とは、雨天時に、ワイパー２２を自動的に作動させる制御をいう。このオートワイパー制御によって実現される機能が、前述のオートワイパー機能に相当する。
【0064】
本実施形態に係るオートワイパー部１２は、陽光センサ３２の検出信号に基づいて、雨天であるか否かを判定する。具体的に、オートワイパー部１２は、陽光センサ３２の検出信号を読み込むとともに、その検出信号に基づいて、雨の有無（すなわち雨天時であるか否か）、及び雨量を判定する。オートワイパー部１２は、雨天であると判定した場合には、車両１００のワイパー２２を自動的に作動させる。ワイパー２２の動作速度は、例えば、判定した雨量に応じた速度に設定される。
【0065】
なお、オートワイパー制御は、ドライバの操作に基づいて、そのオンオフ（オートワイパー制御を行うか否か）を適宜切り替えることができる。また、オートワイパー部１２は、そもそも必須ではない。
【0066】
（画像解析部１３）
画像解析部１３は、車載カメラ４の撮像結果に基づいて、ドライバの閉眼を判定する。具体的に、画像解析部１３は、車載カメラ４によって撮像された顔画像と、該顔画像の時間変化とに基づいて、ドライバの眼の開閉状態を判定する。画像解析部１３によって判定される眼の開閉状態には、ドライバが閉眼しているか否か（閉眼しているか或いは開眼しているか）を示す情報と、ドライバの閉眼時間（閉眼の継続時間）を示す情報と、の両方が含まれる。眼の開閉状態には、ドライバの開眼時間（開眼の継続時間）を含めてもよい。
画像解析部１３は、車載カメラ４の撮像結果に基づいて、ドライバの閉眼を判定する。具体的に、画像解析部１３は、車載カメラ４によって撮像された顔画像と、該顔画像の時間変化とに基づいて、ドライバの眼の開閉状態を判定する。画像解析部１３によって判定される眼の開閉状態には、ドライバが閉眼しているか否か（閉眼しているか或いは開眼しているか）を示す情報と、ドライバの閉眼時間（閉眼の継続時間）を示す情報と、の両方が含まれる。眼の開閉状態には、ドライバの開眼時間（開眼の継続時間）を含めてもよい。
【0067】
例えば、画像解析部１３は、顔画像に基づいて、ドライバの左右それぞれのまぶたの開度と、ドライバの顔向きと、を検出する。画像解析部１３は、その検出結果に基づいて、開眼状態にあるか、閉眼状態にあるか、あるいは、開閉眼を特定できない状態にあるかを、ドライバの左眼及び右眼のそれぞれについて判定する。画像解析部１３は、ドライバの左眼と右眼の双方が閉眼状態にあるときには、そのドライバが閉眼していると判定する。画像解析部１３は、ドライバの左眼及び右眼の少なくとも一方が開眼状態にあるときには、そのドライバが開眼していると判定する。また、画像解析部１３は、ドライバが閉眼していると判定した場合には、その判定が継続した時間を算出し、それをドライバの閉眼時間とする。
【0068】
画像解析部１３はまた、車載カメラ４によって撮像された顔画像と、該顔画像の時間変化とに基づいて、ドライバの視線及びまぶたの動きを検出する。画像解析部１３は、それらの動きに基づいて、ドライバの視認行動及び瞬目活動を検出する。視認行動及び瞬目活動として検出可能な情報には、例えば、視線移動の速度、視線移動の発生頻度、及び瞬きの周期が含まれる。その他、画像解析部１３は、ドライバの口の動き、頭を振る動作、及び姿勢の変化を検出してもよい。
【0069】
画像解析部１３による判定結果は、異常判定部１４を介して第１処理部１５による第１処理に用いられるようになっている。
【0070】
（異常判定部１４）
異常判定部１４は、画像解析部１３による判定結果に基づいて、ドライバが正常に運転できる状態にあるか否かを判定する。具体的に、異常判定部１４は、ドライバの眼の開閉状態及びステアリングの把持状態に基づいて、ドライバが正常に運転できるか否かを判定する。なお、異常判定部１４は、ドライバの眼の開閉状態及びステアリングの把持状態に加えて、ドライバの運転姿勢を用いて判定してもよい。
異常判定部１４は、画像解析部１３による判定結果に基づいて、ドライバが正常に運転できる状態にあるか否かを判定する。具体的に、異常判定部１４は、ドライバの眼の開閉状態及びステアリングの把持状態に基づいて、ドライバが正常に運転できるか否かを判定する。なお、異常判定部１４は、ドライバの眼の開閉状態及びステアリングの把持状態に加えて、ドライバの運転姿勢を用いて判定してもよい。
【0071】
なお、本実施形態では、ドライバが正常に運転できる状態とは、ドライバの眠気が亢進していない状態（例えば、ドライバが居眠りしていない状態）をいう。同様に、ドライバが正常に運転できない状態とは、ドライバの眠気が亢進している状態（例えば、ドライバが居眠りしている状態）をいう。つまり、ドライバが正常に運転できる状態にあるか否かの判定は、本実施形態では、ドライバの眠気が亢進しているか否かの判定に等しい。
【0072】
ここで、ステアリングの把持状態とは、ステアリングを把持しているか否かを示すフラグである。このフラグは、ハンドルセンサ３１の検出信号に基づいて、ＥＣＵ１０によって管理されるようになっている。なお、異常判定部１４の判定にステアリングの把持状態を用いることは、必須ではない。
【0073】
具体的に、異常判定部１４は、以下に説明する第１の亢進条件、第２の亢進条件及び第３の亢進条件のいずれか１つが満足されたときに、ドライバが正常に運転できる状態にない（ドライバの眠気が亢進している）と判定する。これらの亢進条件は、例えば、閉眼の継続時間をカウントするとともに、該継続時間が所定期間以上の場合に満足されたと判定することができる。
【0074】
具体的に、第１の亢進条件は、ドライバの閉眼が第１期間以上にわたって継続した場合に満足される。第１期間は、詳しくは３秒以上７秒以下の期間であって、さらに詳しくは４秒以上６秒以下の期間をいう。第１の眠気条件は、例えば、ステアリングの把持状態を問わない条件である。仮にドライバがステアリングを把持していたとしても、ドライバの閉眼時間が第１期間以上になれば、異常判定部１４は、ドライバの眠気が亢進していると判定する。
【0075】
第２の亢進条件は、ドライバの開眼が第２期間以上にわたって継続し、かつドライバがステアリングを把持していないと判定された場合に満足される。第２期間の長さは、少なくとも第１期間未満である。第２期間は、詳しくは２秒以上４秒以下の期間をいう。
【0076】
第３の亢進条件では、まず、眼の閉眼状態とは異なる観点から眠気の有無を判定される。その判定によって眠気が有ることが検知された場合、その検知から第３期間以内における閉眼時間が判定される。そして、第３期間以内における閉眼時間が前記第２期間以上にわたって継続した場合に、第３の亢進条件が満足される。第３期間は、少なくとも第２期間以上である。第３期間は、詳しくは１００秒以上１４０秒以下の期間であって、さらに詳しくは１１０秒以上１３０秒以下の期間をいう。
【0077】
ここで、眼の閉眼状態とは異なる観点からの眠気の有無の判定とは、例えば、視線移動の速度、視線移動の発生頻度、瞬きの頻度、及び眼以外の顔画像の変化に基づいた判定をいう。
【0078】
例えば、視線移動が速くかつ頻繁であり、その上、瞬きの周期が安定している場合、異常判定部１４は、「ドライバは全く眠くない」と判定する（眠気レベル＝１）。また、視線移動が遅く、唇が開いている場合、異常判定部１４は、「ドライバはやや眠い」と判定する（眠気レベル＝２）。また、瞬きがゆっくりかつ頻繁であり、口の動きがある場合、異常判定部１４は、「ドライバは眠い」と判定する（眠気レベル＝３）。また、意識的と思われる瞬きがあったり、視線移動及び瞬きが遅かったり、頭を振る動作があったり、あくびが頻発していたりした場合、異常判定部１４は、「ドライバはかなり眠い」と判定する（眠気レベル＝４）。また、ドライバがまぶたを閉じていたり、頭が前後に倒れていたりした場合、異常判定部１４は、「ドライバは非常に眠い」と判定する（眠気レベル＝５５）。
【0079】
本実施形態に係る異常判定部１４は、前記第３の亢進条件の判定に際し、例えば、前記眠気レベルが３－５の場合に、「ドライバに眠気がある」と判定する。その判定結果と、第３期間以内における閉眼時間に基づいて、前述のようにドライバの眠気亢進が判定されるようになっている。
【0080】
（第１処理部１５）
第１処理部１５は、画像解析部１３及び異常判定部１４による閉眼の判定結果に基づいて、第１処理を実行する。第１処理とは、車室内への警告発令、又は、車両１００の自動停車を指令する処理をいう。
第１処理部１５は、画像解析部１３及び異常判定部１４による閉眼の判定結果に基づいて、第１処理を実行する。第１処理とは、車室内への警告発令、又は、車両１００の自動停車を指令する処理をいう。
【0081】
具体的に、本実施形態に係る第１処理部１５は、ドライバが正常に運転できない状態にあると判定された場合に、第１処理を実行する。具体的に、第１処理が開始されると、第１処理部１５はまず、車両１００の非常点滅表示灯２３の点滅を開始するとともに、ディスプレイ２４への表示により、ドライバ又は乗員に対して警告を発令する。ディスプレイ２４の表示内容は、例えば、車両１００の自動停車を開始することと、特定のユーザ操作によって構成される、第１処理のキャンセル手順とによって構成してもよい。
【0082】
その後、ドライバが正常に運転できる状態に復帰せず、かつ第１処理がキャンセルされない場合、第１処理部１５は、非常点滅表示灯２３に加え、ブレーキランプの点滅とホーン２５の吹鳴を開始させる。それとともに、第１処理部１５は、動力源１００ａ等を制御することで、車両１００を減速及び停止させる。
【0083】
（第２処理部１６）
図５Ａは、第１の例外条件の判定について説明するための図である。図５Ｂは、第２の例外条件の判定について説明するための図である。図５Ａ及び図５Ｂの横軸は、時間［ｓｅｃ］である。図５Ａの縦軸は、陽光センサ３２の出力値Ｖ１、又は、該出力値Ｖ１の直近の移動平均Ａ１である。図５Ａの破線は、第１閾値Ｔ１を示している。また、図５Ｂの縦軸は、陽光センサ３２の出力値Ｖ１から、該出力値Ｖ１の直近の移動平均Ａ１を減算した値Ｄ１（＝Ｖ１－Ａ１）を示している。図５Ｂの破線は、第２閾値Ｔ２を示している。
図５Ａは、第１の例外条件の判定について説明するための図である。図５Ｂは、第２の例外条件の判定について説明するための図である。図５Ａ及び図５Ｂの横軸は、時間［ｓｅｃ］である。図５Ａの縦軸は、陽光センサ３２の出力値Ｖ１、又は、該出力値Ｖ１の直近の移動平均Ａ１である。図５Ａの破線は、第１閾値Ｔ１を示している。また、図５Ｂの縦軸は、陽光センサ３２の出力値Ｖ１から、該出力値Ｖ１の直近の移動平均Ａ１を減算した値Ｄ１（＝Ｖ１－Ａ１）を示している。図５Ｂの破線は、第２閾値Ｔ２を示している。
【0084】
第２処理部１６は、第１の例外条件と、第２の例外条件と、をそれぞれ判定し、第１及び第２の例外条件が双方とも満足された場合に、第２処理の実行を指令する。第２処理とは、第１処理部１５による第１処理の実行を遅延又は抑制する処理をいう。
【0085】
ここで、第１の例外条件とは、車載センサとしての陽光センサ３２の出力値が第１閾値Ｔ１を超えた場合又は第１閾値Ｔ１以上の場合に満足される条件をいう。本実施形態では、一例として前者の場合（出力値が第１閾値Ｔ１を超えた場合）が採用されている。第２の例外条件とは、現時点における出力値から該出力値の直近の移動平均を減算した値が第２閾値Ｔ２を超えた場合又は該第２閾値Ｔ２の場合に満足される条件をいう。本実施形態では、一例として前者の場合（減算した値が第２閾値Ｔ２を超えた場合）が採用されている。第１及び第２の例外条件は、それぞれ、本実施形態における「第１条件」及び「第２条件」の例示である。
【0086】
なお、ここでいう「現時点」とは、第１の例外条件の判定タイミング、例えば第１の例外条件が満足されたタイミングとしてもよいし、第１の例外条件が満足されたタイミングから若干遅れたタイミングとしてもよい。
【0087】
まず、図５Ａに概念的に例示したように、第２処理部１６は、現時点における陽光センサ３２の出力値Ｖ１が、第１閾値Ｔ１を超えているか否か（第１の例外条件を満足しているか否か）を判定する。第１閾値Ｔ１は、図４の第２領域Ｒ２又は第３領域Ｒ３に属する値である。具体的に、第１閾値Ｔ１は、詳しくは５０００Ｌｘ以上９０００Ｌｘ以下、さらに詳しくは６０００Ｌｘ以上８０００Ｌｘ以下の照度に対応した値とされている。
【0088】
また、図５Ｂに概念的に例示したように、第２処理部１６は、第１の例外条件の判定と並行して、陽光センサ３２の出力値の移動平均を算出する。第２処理部１６が算出する移動平均は、直帰の移動平均Ａ１である。すなわち、この移動平均Ａ１は、現時点の出力値から、所定期間遡った出力値にかけての単純移動平均である。
【0089】
例えば、１分間あたり５個の周期で陽光センサ３２の検出信号がＥＣＵ１０に入力されているとした場合、仮に所定期間＝４分とすると、本実施形態では直近２０個のデータによる移動平均が算出されることになる。
【0090】
次いで、第２処理部１６は、現時点の陽光センサ３２の出力値Ｖ１から、算出した移動平均Ａ１の値を減算する。そして、第２処理部１６は、その減算によって得られた値Ｄ１が、第２閾値Ｔ２を超えているか否か（第２の例外条件を満足しているか否か）を判定する。第２閾値Ｔ２は、図５Ａと図５Ｂとの比較から見て取れるように、第１閾値Ｔ１未満の閾値である（Ｔ２＜Ｔ１）。言い換えると、第１閾値Ｔ１は、第２閾値Ｔ２よりも大きい。
【0091】
つまり、ｎを正の整数とし、ｔｎを第１及び第２の例外条件の判定時刻とすると、第２処理部１６は、時刻ｔｎにおいて、以下の条件式（１）及び（２）が同時に成立するか否かを判定することになる。
【0092】
ｓ（ｔｎ）＞Ｔ１ …（１）
ｓ（ｔｎ）－ａ（ｔｎ）＞Ｔ２ …（２）
上式（１）及び（２）において、ｓ（ｔｎ）は時刻ｔｎにおける陽光センサ３２の出力値Ｖ１であり、ａ（ｔｎ）は時刻ｔｎにおける陽光センサ３２の出力値の直近の移動平均Ａ１である。ｍを正の整数とすると、ａ（ｔｎ）は、下式（３）のように表すことができる。上述した構成例の場合、ｍ＝２０－１＝１９である。
ｓ（ｔｎ）－ａ（ｔｎ）＞Ｔ２ …（２）
上式（１）及び（２）において、ｓ（ｔｎ）は時刻ｔｎにおける陽光センサ３２の出力値Ｖ１であり、ａ（ｔｎ）は時刻ｔｎにおける陽光センサ３２の出力値の直近の移動平均Ａ１である。ｍを正の整数とすると、ａ（ｔｎ）は、下式（３）のように表すことができる。上述した構成例の場合、ｍ＝２０－１＝１９である。
【0093】
ａ（ｔｎ）＝ｓ（ｔｎ）＋ｓ（ｔｎ－１）＋…＋ｓ（ｔｎ－ｍ）／（ｍ－１） …（３）
なお、式（３）においてｓ（ｔｎ）から起算することは、必須ではない。ｓ（ｔｎ－１）、ｓ（ｔｎ－２）等、ｓ（ｔｎ）から所定時刻遡った値から、移動平均の算出を開始してもよい。
なお、式（３）においてｓ（ｔｎ）から起算することは、必須ではない。ｓ（ｔｎ－１）、ｓ（ｔｎ－２）等、ｓ（ｔｎ）から所定時刻遡った値から、移動平均の算出を開始してもよい。
【0094】
上式（２）の左辺が、上述した減算値Ｄ１に相当する。例えば図５Ａでは、時刻ｔ１以降、第１の例外条件が満足しているとみなすことができる。一方、図５Ｂの例では、時刻ｔ２以上かつ時刻ｔ３以下の期間内に限り、第２の例外条件が満足されているとみなすことができる。
【0095】
【0096】
このように、第１及び第２の例外条件が双方とも満足されている場合、第２処理部１６は、閉眼時間（閉眼の継続時間）のカウントをリセットする。この場合、異常判定部１４による判定、特に「ドライバが正常に運転できる状態にない」という判定が猶予されることになるから、そのことで、第１処理部１５による第１処理の実行が、遅延又は抑制されることになる。
【0097】
一方、図５Ｃは、第２の例外条件が未成立のケースを説明するための図５Ｂ対応図である。図５Ｃの横軸は時間［ｓｅｃ］である。図５Ｃの縦軸は、陽光センサ３２の出力値Ｖ２（≠Ｖ１）から、該出力値Ｖ２の直近の移動平均Ａ２（≠Ａ１）を減算した値Ｄ２（＝Ｖ２－Ａ２）を示している。図５Ｃの破線は、図５Ｂと同様に第２閾値Ｔ２を示している。
【0098】
例えば図５Ｃに示すように、前記減算値Ｄ２が第２閾値Ｔ２を上回らず、第２の例外条件が満足されない場合、第２処理部１６は、閉眼時間（閉眼の継続時間）のカウントをリセットしない。この場合、異常判定部１４による判定、特に「ドライバが正常に運転できる状態にない」という判定は猶予されないから、第１処理部１５による第１処理の実行が、滞りなく開始されることになる。第１の例外条件が満足されない場合も同様である。
【0099】
＜眠気亢進に関する制御の具体例＞
以下、眠気亢進に関する制御の具体例について、図６及び図７を参照して説明する。ここで、図６は、ドライバ状態判定装置１が行う処理を例示するフローチャートである。図７は、第１及び第２の例外条件に関する処理を例示するフローチャートである。
以下、眠気亢進に関する制御の具体例について、図６及び図７を参照して説明する。ここで、図６は、ドライバ状態判定装置１が行う処理を例示するフローチャートである。図７は、第１及び第２の例外条件に関する処理を例示するフローチャートである。
【0100】
まず、図６のステップＳ１において、ＥＣＵ１０がタイマ１０ａのカウントをリセットする。次いで、ステップＳ２において、ＥＣＵ１０が各種信号を読み込む。ＥＣＵ１０が読み込む信号には、ハンドルセンサ３１及び陽光センサ３２の検出信号と、車載カメラ４によって取得された画像信号と、タイマ１０ａによるカウント時間と、が含まれる。タイマ１０ａによるカウント時間に、画像解析部１３から出力される情報を用いてもよい。
【0101】
続くステップＳ３において、画像解析部１３が、車載カメラ４によって取得された画像を解析する。それに続くステップＳ４～Ｓ８において、異常判定部１４が、第１の亢進条件、第２の亢進条件、及び第３の亢進条件のいずれかが満足されたか否かを判定する。
【0102】
具体的に、ステップＳ４において、異常判定部１４は、画像解析部１３による解析結果に基づいて、ドライバが閉眼しているか否かを判定する。ステップＳ４の判定がＮＯの場合、ＥＣＵ１０は、以降の処理をスキップしてリターンする。この場合、第１処理は行われない。
【0103】
一方、ステップＳ５の判定がＹＥＳの場合、ＥＣＵ１０は、制御プロセスをステップＳ５に進める。このステップＳ５において、異常判定部１４は、ドライバの閉眼時間が第２期間に達したか否かを判定する。この判定は、タイマ１０ａによるカウント時間を用いて行われるようになっている。
【0104】
ステップＳ５の判定がＹＥＳの場合、ＥＣＵ１０は、制御プロセスをステップＳ６に進める。このステップＳ６において、ＥＣＵ１０は、ディスプレイ２４の表示制御及びホーン２５の鳴動を通じて、ドライバに警報を発令する。
【0105】
そして、ステップＳ６から続くステップＳ７において、異常判定部１４は、ドライバがステアリングを把持しているか否か（ハンドル把持？）を判定する。この判定は、ハンドルセンサ３１の検出信号を用いて行うことができる。
【0106】
ステップＳ７の判定がＮＯの場合、第２の亢進条件が満足される。この場合、ＥＣＵ１０は制御プロセスをステップＳ１１に進め、第１処理部１５に第１処理を指令させる。このステップＳ１１では、前述した第１処理が実行される。
【0107】
一方、ステップＳ７の判定がＹＥＳの場合、ＥＣＵ１０は制御プロセスをステップＳ８に進める。このステップＳ８において、異常判定部１４は、ドライバの閉眼時間が第１期間に達したか否かを判定する。この判定は、タイマ１０ａによるカウント時間を用いて行われるようになっている。
【0108】
ステップＳ８の判定がＹＥＳの場合、第１の亢進条件が満足される。この場合、ＥＣＵ１０は制御プロセスをステップＳ１１に進め、第１処理部１５に第１処理を指令させる。このステップＳ１１では、前述した第１処理が実行される。
【0109】
一方、ステップＳ５又はステップＳ８の判定がＮＯの場合、ＥＣＵ１０は、制御プロセスをステップＳ９に進める。このステップＳ９において、ＥＣＵ１０は、タイマ１０ａをカウントアップする。これにより、カウント時間が加算される。
【0110】
【0111】
このステップＳ２１では、ＥＣＵ１０が各種信号を読み込む。ＥＣＵ１０が読み込む信号には、陽光センサ３２の検出信号と、タイマ１０ａによるカウント時間と、が含まれる。
【0112】
続くステップＳ２２において、第２処理部１６は、陽光センサ３２の出力値の移動平均、特に直近の移動平均を算出する。なお、ステップＳ２２は、後述のステップＳ２３の判定と並行して行ってもよいし、そのステップＳ２３と、同じく後述のステップＳ２４との間のタイミングで実行してもよい。
【0113】
ステップＳ２３において、第２処理部１６は、陽光センサ３２の現時点の出力値が、図５Ａに例示した第１閾値Ｔ１を超えているか否かを判定する。この判定がＮＯの場合、ＥＣＵ１０は、図７に示す制御プロセスを終了し、図６のステップＳ２に戻る。この場合、タイマ１０ａによるカウント時間が、引き続き保持されることになる。ステップＳ２３は、第１の例外条件が満足しているか否かの判定の例示である。
【0114】
一方、ステップＳ２３の判定がＹＥＳの場合、ＥＣＵ１０は、制御プロセスをステップＳ２４に進める。なお、ステップＳ２４の処理は、ステップＳ２３の判定と並行して行ってもよいし、そのステップＳ２３の判定を行う前に実行してもよい。
【0115】
ステップＳ２４において、第２処理部１６は、陽光センサ３２の現時点の出力値から直近の移動平均を減算した値が、図５Ｂ及び図５Ｃに例示した第２閾値Ｔ２を超えているか否かを判定する。この判定がＮＯの場合、ＥＣＵ１０は、図７に示す制御プロセスを終了し、図６のステップＳ２に戻る。この場合、タイマ１０ａによるカウント時間が、引き続き保持されることになる。ステップＳ２４は、第２の例外条件が満足しているか否かの判定の例示である。
【0116】
一方、ステップＳ２４の判定がＹＥＳの場合、ＥＣＵ１０は、制御プロセスをステップＳ２５に進める。ステップＳ２５において、第２処理部１６がタイマ１０ａによるカウント時間をリセットする（カウント時間をゼロに戻す）。その後、ＥＣＵ１０は、制御プロセスを図６のステップＳ２に戻す。この場合、タイマ１０ａによるカウント時間が、新たにゼロからカウントされることになる。
【0117】
なお、ステップＳ４～ステップＳ８の処理に際し、異常判定部１４が、第３の亢進条件が成立したか否かを判定してもよい。具体的に、異常判定部１４は、ステップＳ４に先だって眠気の有無を判定する。ここでいう「眠気」の詳細は、前述した通りである。眠気が有ると判定された場合（例えば眠気レベル＝３－５の場合）、異常判定部１４は、その判定タイミングを起点として経過時間をカウントする。異常判定部１４は、その経過時間が前述の第３期間に達する前に、ドライバの閉眼時間が第２期間を超えたか否かを判定する。そして、異常判定部１４は、閉眼時間が第２期間を超えた場合には制御プロセスをステップＳ１１に進める一方、第２期間を超えていない場合は、制御プロセスをステップＳ９及びステップＳ１１に進め、閉眼時間をカウントアップする。
【0118】
＜ドライバが眩しさを感じる状況について＞
図８は、陽光センサの出力及びその移動平均の実測値を例示する図である。図８の横軸は、時間［ｓｅｃ］である。図８の縦軸は、陽光センサ３２の出力値Ｌ１、又は、該出力値Ｌ１の直近の移動平均Ｌ２である。出力値Ｌ１の下限値は、０の値を示している。出力値の上限値は、１０２４の値を示している。
図８は、陽光センサの出力及びその移動平均の実測値を例示する図である。図８の横軸は、時間［ｓｅｃ］である。図８の縦軸は、陽光センサ３２の出力値Ｌ１、又は、該出力値Ｌ１の直近の移動平均Ｌ２である。出力値Ｌ１の下限値は、０の値を示している。出力値の上限値は、１０２４の値を示している。
【0119】
本願発明者らは、例えば、トンネルから出た直後に西日が差し込んだ場合のように、ドライバが正常であったとしても、意図せずして閉眼に至る状況について検討した。その検討に際し、本願発明者らは、ドライバの眼の明順応に着目した。
【0120】
すなわち、本願発明者らによれば、陽光の明るさ、光量等の値そのものばかりでなく、その値が短期間で大きく増加した場合、眼の明順応が追いつかない可能性がある。その場合、ドライバに意図せぬ閉眼を招き得ることが新たに判った。
【0121】
明順応に係る判定を行うためには、明るい側における光量の変化を、細やかに検出することが求められる。しかしながら、いわゆるオートライト制御に用いられる陽光センサ３２は、図４を用いて説明したように、明るい側の分解能が、暗い側ほど優れていない。実際のところ、図８の出力値（センサ出力値）Ｌ１に例示するように、ある程度明るい環境下では、陽光センサ３２の出力値Ｌ１は、その上限値付近で僅かに変化するようになっていることが知られていた。
【0122】
そのため、陽光センサ３２は、明るい側における光量の増減を、その出力値に細やかに反映させることはできない。ゆえに、陽光センサ３２は、従来の知見だけでは、意図せぬ閉眼の判定に用いるには不都合であった。
【0123】
こうした課題に対し、本願発明者らは、光量の増加を細やかに判定するために、陽光センサ３２の出力値それ自体に加えて、その直近の移動平均を用いることを新たに着想した。この移動平均の時間変化は、ドライバの眩しさへの慣れの進行を示す、いわば陽光順応曲線とみなすことができる。
【0124】
例えば、図９の囲み部Ｃ１に示すように、陽光センサ３２の出力値Ｌ１が０からＶ１に短期間で増加したとき、その直近の移動平均Ｌ２は、出力値Ｌ１よりも緩やかに増加する。移動平均Ｌ２は、出力値Ｌ１と同様に０からＶ１に変化するものの、その変化が完了するタイミングは、出力値Ｌ１よりも遅れることになる。
【0125】
すなわち、陽光センサ３２の出力値Ｌ１が短期間で増加したとき、その出力値Ｌ１から移動平均Ｌ２を減算した値は、正の値となりつつ、一時的に増加することになる。
【0126】
本願発明者らによれば、移動平均Ｌ２が出力値Ｌ１に追いつかない状況（Ｌ１＞Ｌ２の状況）では、ドライバが眩しさに慣れていないと判定することができる。一方、移動平均Ｌ２が出力値Ｌ１に追いついた状況（Ｌ１≒Ｌ２の状況）では、ドライバが眩しさに慣れたと判定することができる。前者の状況では、出力値Ｌ１から移動平均Ｌ２を減算した値は、一時的に増加することになる（図８の両矢印Ａｒ１を参照）。その後、後者の状況に至ると、その減算した値の大きさは、減少に転じることになる（図８の両矢印Ａｒ２を参照）。出力値Ｌ１から移動平均Ｌ２を減算した値を用いることで、ドライバが眩しさに慣れているか否かを判定することが可能となる。
【0127】
本実施形態に係る第２処理部１６は、こうした知見を反映した構成とされている。
【0128】
すなわち、本願発明者らは、以下に挙げる２つの条件（Ａ）及び（Ｂ）が双方とも満足された場合に、明順応に起因した閉眼を招き得ると考えた。
【0129】
・出力値Ｌ１＞第１閾値Ｔ１ …（Ａ）
・出力値Ｌ１－移動平均Ｌ２＞第２閾値Ｔ２…（Ｂ）
これらの条件（Ａ）及び（Ｂ）は、それぞれ、前記式（１）及び（２）に示した第１及び第２の例外条件に他ならない。第１の例外条件が満足されると、ドライバが、眩しさを感じ得る環境下にあると判断することができる。さらに、第２の例外条件が満足されると、車内に差し込む明るさが、短期間のうちに、ドライバが眩しさを感じ得るほど大きく増加したものと判断することができる。
・出力値Ｌ１－移動平均Ｌ２＞第２閾値Ｔ２…（Ｂ）
これらの条件（Ａ）及び（Ｂ）は、それぞれ、前記式（１）及び（２）に示した第１及び第２の例外条件に他ならない。第１の例外条件が満足されると、ドライバが、眩しさを感じ得る環境下にあると判断することができる。さらに、第２の例外条件が満足されると、車内に差し込む明るさが、短期間のうちに、ドライバが眩しさを感じ得るほど大きく増加したものと判断することができる。
【0130】
したがって、第１及び第２の例外条件が双方とも満足された場合、眼の明順応が追いつかず、ドライバに意図せぬ閉眼を招き得る状況にあると判断することが可能になる。眠気等の要因ではなく、眩しさのあまり意図せずして閉眼した場合、そのドライバは正常であると判定することができる。
【0131】
そして、図７に例示したように、第２処理部１６は、第１及び第２の例外条件が双方とも満足された場合、つまり、ドライバが正常であると判定された場合、第１処理部１５による第１処理の実行を遅延又は抑制する。これにより、ドライバ状態の誤検知に起因した第１処理の実行を、遅延又抑制することが可能になる。
【0132】
そして、本実施形態に係る構成は、図２に例示したように、比較的一般的な陽光センサ３２を用いて実現することができる。また、第１及び第２の例外条件の判定は、高度な日照プログラムを用いずとも実現することができる。ゆえに、車両１００のコストアップを招くことなく、ドライバの状態をより正確に判定することができる。
【0133】
また、図２のオートライト部１１に関連して説明したように、本実施形態に係る陽光センサ３２は、ヘッドランプの２１自動点灯に使用可能な照度センサ、いわゆるオートライトセンサである。そのオートライトセンサに、第１及び第２の例外条件を判定するためのセンサを兼用させることで、車両１００のコストアップを抑制する上で有利となる。
【0134】
また、図２のオートワイパー部１２に関連して説明したように、本実施形態に係る陽光センサ３２は、ワイパー２２の自動動作に使用可能な照度センサ、いわゆるレインセンサである。そのレインセンサに、第１及び第２の例外条件を判定するためのセンサを兼用させることで、車両１００のコストアップを抑制する上で有利となる。
【0135】
また、図７のステップＳ２５に例示したように、第２処理部１６は、第１及び第２の例外条件が双方とも満足された場合に、閉眼時間（閉眼の継続時間）のカウントをリセットする。閉眼時間のカウントをリセットすることで、第１処理を実行させないようにすることができる。これにより、ドライバ状態の誤検知に起因した第１処理の実行を、遅延又抑制する上で有利になる。
【0136】
また、図５Ａ及び図５Ｂに例示したように、第１閾値Ｔ１を第２閾値Ｔ２よりも大きく設定することで、ドライバが眩しさを感じ得る環境下にあることを、より確実に判定することが可能になる。このことは、ドライバ状態のより正確な判定に資する。
【0137】
＜センサ実測値を用いた具体例＞
図９Ａ、図９Ｂ、図９Ｃ及び図９Ｄは、陽光センサ３２の出力値及び移動平均の実測値を例示している。図９Ａ、図９Ｂ、図９Ｃ及び図９Ｄに示す値は、同じ陽光センサ３２を用いつつも、測定地点、測定時間、測定時の天候等が相違している。
図９Ａ、図９Ｂ、図９Ｃ及び図９Ｄは、陽光センサ３２の出力値及び移動平均の実測値を例示している。図９Ａ、図９Ｂ、図９Ｃ及び図９Ｄに示す値は、同じ陽光センサ３２を用いつつも、測定地点、測定時間、測定時の天候等が相違している。
【0138】
ここで、各図の横軸は、時間［ｓｅｃ］である。横軸の下限値から上限値に至るまでの区間は、５分～１５分程度の時間間隔を示している。各グラフの縦軸は、陽光センサ３２の出力値又は移動平均を示している。各グラフにおいて、太線が出力値であり、細線が移動平均である。出力値について縦軸の下限値から上限値に至るまでの区間は、０から１０２４までの値の推移を示している。
【0139】
図９Ａは、例えば日中の測定値を例示している。図９Ａの場合、陽光センサ３２の出力値は、時刻Ｔａ１，Ｔａ２及びＴａ３を除いて、その上限値付近を推移している。これは、前述のように明るい側の分解能が、相対的に大きいことを反映している。
【0140】
そして、図９Ａの時刻Ｔａ１及びＴａ２では、陽光センサ３２の出力値が、その下限値よりも有意に大きい値まで急峻に減少した後、所定時間後に、急峻に増加していることが見て取れる。こうした振る舞いは、例えば車両１００の進行方向に沿って延びる橋下のように、日光を十分に遮らないものの、日光の遮断時間が比較的長くなるような構造物を、車両１００が通過したことを示唆している。
【0141】
このような状況下では、第１の例外条件（出力値＞第１閾値Ｔ１）こそ満足されるものの、第２の例外条件（移動平均＞第２閾値Ｔ２）は満足されないと考えられる。この場合、日光が十分に遮断されないため、眼の明順応が追いついていると考えられる。第２処理部１６は、第１処理の実行を遅延又は抑制しない。ドライバの閉眼時間次第でドライバが正常ではないと判定されて、第１処理が開始される。
【0142】
一方、図９Ａの時刻Ｔａ３では、陽光センサ３２の出力値が、その下限値付近まで急峻に減少した後、上限付近まで急峻に増加していることが見て取れる。こうした振る舞いは、例えばトンネルのように、日光が完全に遮られるような構造物を、車両１００が通過したことを示唆している。
【0143】
このような状況下では、第１の例外条件ばかりでなく、第２の例外条件も満足されると考えられる。この場合、眼の明順応が追いついておらず、眩しさに起因した閉眼が想定される。第２処理部１６は、第１処理の実行を遅延又は抑制する。ドライバの閉眼時間に関わらず、ドライバが正常ではないとの判定が保留される。その結果、第１処理の実行が妨げられる。
【0144】
図９Ｂは、例えば夕方又は雨天時の測定値を例示している。図９Ｂの場合、陽光センサ３２の出力値は、その上限値よりも有意に低い値を推移している。これは、夕方ではあるものの車内に西日が差し込んでいないか、或いは、雨天時であることを示唆している。
【0145】
そして、図９Ｂの時刻Ｔｂ１では、陽光センサ３２の出力値が、その上限値よりも有意に低い値から下限値まで急峻に減少した後、同じく上限値よりも有意に低い値まで急峻に増加していることが見て取れる。こうした振る舞いは、例えばトンネルのように、日光が完全に遮られるような構造物を、車両１００が通過したことを示唆している。
【0146】
このような状況下では、第２の例外条件こそ満足されるものの、第１の例外条件は満足されないと考えられる。この場合、そもそもドライバは眩しさを感じていないと考えられる。第２処理部１６は、第１処理の実行を遅延又は抑制しない。ドライバの閉眼時間次第でドライバが正常ではないと判定されて、第１処理が開始される。
【0147】
図９Ｃは、例えば日中の測定値を例示している。図９Ｃの場合、陽光センサ３２の出力値は、時間方向の全域において、その上限値付近を推移している。こうした振る舞いは、例えば車両１００の進行方向に直交する橋下等、日光を完全に遮ることなく、それでいて日光の遮断時間も比較的短くなるような構造物を、車両１００が通過したことを示唆している。
【0148】
このような状況下では、第１の例外条件（出力値＞第１閾値Ｔ１）こそ満足されるものの、第２の例外条件（移動平均＞第２閾値Ｔ２）は満足されないと考えられる。この場合、日光が十分に遮断されないため、眼の明順応が追いついていると考えられる。第２処理部１６は、第１処理の実行を遅延又は抑制しない。ドライバの閉眼時間に応じてドライバが正常ではないと判定されて、第１処理が開始される。
【0149】
図９Ｄは、例えば日中の測定値を例示している。図９Ｄの場合、陽光センサ３２の出力値は、その上限値と下限値とを行き来するように急峻に増減している。図９Ｄに示すように、出力値が急峻に増減するような状況であっても、その移動平均は緩慢に変化することになる。移動平均を用いることで、ドライバが眩しさを感じている否かの判定を安定させることができる。
【符号の説明】
【0150】
１ ドライバ状態判定装置
２ 車両機器
２１ ヘッドランプ
３ 車載センサ
３２ 陽光センサ（車載センサ）
４ 車載カメラ
５ 通信経路
１０ ＥＣＵ（コントローラ）
１００ 車両
Ｔ１ 第１閾値
Ｔ２ 第２閾値
２ 車両機器
２１ ヘッドランプ
３ 車載センサ
３２ 陽光センサ（車載センサ）
４ 車載カメラ
５ 通信経路
１０ ＥＣＵ（コントローラ）
１００ 車両
Ｔ１ 第１閾値
Ｔ２ 第２閾値
【図1】
【図2】
【図3】
【図4】
【図5A】
【図5B】
【図5C】
【図6】
【図7】
【図8】
【図9A】
【図9B】
【図9C】
【図9D】