特許 7567821 自動運行装置、通知制御装置、通知制御方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-10-07

(45)【発行日】2024-10-16

(54)【発明の名称】自動運行装置、通知制御装置、通知制御方法

(51)【国際特許分類】

   G08G 1/16 20060101AFI20241008BHJP

   G01C 21/36 20060101ALI20241008BHJP

   B60W 50/14 20200101ALI20241008BHJP

   B60W 60/00 20200101ALI20241008BHJP

【ＦＩ】

G08G1/16 F

G01C21/36

B60W50/14

B60W60/00

【請求項の数】 20

(21)【出願番号】P 2022009649

(22)【出願日】2022-01-25

(65)【公開番号】P2023058413

(43)【公開日】2023-04-25

【審査請求日】2024-02-14

(31)【優先権主張番号】P 2021168161

(32)【優先日】2021-10-13

(33)【優先権主張国・地域又は機関】JP

(73)【特許権者】

【識別番号】000004260

【氏名又は名称】株式会社デンソー

(74)【代理人】

【氏名又は名称】矢作 和行

(74)【代理人】

【識別番号】100121991

【弁理士】

【氏名又は名称】野々部 泰平

(74)【代理人】

【識別番号】100145595

【弁理士】

【氏名又は名称】久保 貴則

(72)【発明者】

【氏名】久米 拓弥

(72)【発明者】

【氏名】和泉 一輝

【審査官】佐々木 佳祐

(56)【参考文献】

【文献】特開２０２１－１１３０４３（ＪＰ，Ａ）

【文献】特開２０１７－２００７８６（ＪＰ，Ａ）

【文献】米国特許出願公開第２０１８／０２０３４５１（ＵＳ，Ａ１）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０８Ｇ １／１６

Ｇ０１Ｃ ２１／３６

Ｂ６０Ｗ ５０／１４

Ｂ６０Ｗ ６０／００

(57)【特許請求の範囲】

【請求項1】

運転席に着座している人物である運転席乗員の睡眠を許容する自動化レベルでの自動運転を実施可能な自動運行装置であって、
自車両の走行経路上の渋滞にかかる情報を取得する渋滞情報取得部（Ｆ２１）と、
報知デバイス（２１、２２）を介して前記運転席乗員へ前記渋滞に係る情報を通知するための処理を実施する渋滞通知処理部（Ｆ６１）と、
前記運転席乗員の状態をセンシングする乗員状態センサ（１６）からの入力信号に基づき、前記運転席乗員が眠っているか否かを取得する乗員状態取得部（Ｆ３）と、を備え、
前記渋滞通知処理部は、前記自動運転が実行されている間は、前記運転席乗員が眠っているか否かに応じて、前記渋滞に関する通知の態様を変更する自動運行装置。

【請求項2】

請求項１に記載の自動運行装置であって、
前記乗員状態取得部は、前記運転席乗員が眠っている場合、その眠りの深さである睡眠深度を判定するように構成されており、
前記渋滞通知処理部は、前記自動運転が実行されている間は、前記睡眠深度に応じて前記渋滞に関する通知を行うか否かを変更するように構成されている自動運行装置。

【請求項3】

請求項２に記載の自動運行装置であって、
前記渋滞通知処理部は、前記自動運転が実行されている間、前記睡眠深度が所定の基準値未満である場合には前記渋滞に関する通知を行う一方、前記睡眠深度が前記基準値以上である場合には前記渋滞に関する通知を行わないように構成されている自動運行装置。

【請求項4】

請求項２又は３に記載の自動運行装置であって、
前記渋滞情報取得部は、前記渋滞による到着予定時刻の遅延量である到着遅延量又は前記渋滞の長さを示す渋滞長を取得し、
前記渋滞通知処理部は、前記自動運転が実行されている間は、前記到着遅延量及び前記渋滞長の何れか一方と、前記運転席乗員が眠っているか否かに基づいて、前記渋滞に関する通知の態様を変更する自動運行装置。

【請求項5】

請求項４に記載の自動運行装置であって、
前記渋滞通知処理部は、
入力装置からの信号又は予め登録されているデータに基づいて、前記運転席乗員が許容する渋滞による遅延時間を示す許容閾値を取得し、
前記自動運転が実行されており、前記運転席乗員が眠っている状況においては、前記到着遅延量又は前記渋滞長が前記許容閾値未満である場合には前記渋滞に関する通知を中止する一方、前記到着遅延量又は前記渋滞長が前記許容閾値以上である場合には前記渋滞に関する通知を実施するように構成されている自動運行装置。

【請求項6】

請求項１から５の何れか１項に記載の自動運行装置であって、
前記乗員状態取得部は、同乗者の状態を検出する同乗者センサからの信号に基づき、同乗者が起きているか否かも判定可能に構成されており、
前記渋滞通知処理部は、前記運転席乗員が眠っている場合であっても、前記同乗者が起きている場合には、前記渋滞に関する詳細情報を前記報知デバイスとしてのディスプレイに表示するように構成されている自動運行装置。

【請求項7】

請求項１から６の何れか１項に記載の自動運行装置であって、
前記渋滞通知処理部は、入力装置からの信号又は予め登録されているデータに基づいて、渋滞による遅延を前記運転席乗員が許容しているか否かの設定情報を取得し
前記渋滞による遅延を前記運転席乗員が許容することを取得できている場合には、前記自動運転が実行されている間は、前記渋滞に関する通知を停止するように構成されている自動運行装置。

【請求項8】

運転席乗員の睡眠を許容する自動化レベルでの自動運転を実施可能な自動運行装置であって、
自車両の走行経路上の渋滞にかかる情報を取得する渋滞情報取得部（Ｆ２１）と、
報知デバイス（２１、２２）を介して前記運転席乗員へ渋滞に係る情報を通知するための処理を実施する渋滞通知処理部（Ｆ６１）と、を備え、
前記渋滞情報取得部は、前記渋滞による到着予定時刻の遅延量である到着遅延量又は前記渋滞の長さを示す渋滞長を取得し、
前記渋滞通知処理部は、前記自動運転が実行されている間は、前記到着遅延量又は前記渋滞長に応じて、前記自動運転を実行における前記渋滞に関する通知の態様を変更する自動運行装置。

【請求項9】

請求項８に記載の自動運行装置であって、
前記渋滞通知処理部は、前記自動運転が実行されている間は、前記到着遅延量又は前記渋滞長が所定の許容閾値以上である場合には前記渋滞に関する通知を実施する一方、前記到着遅延量又は前記渋滞長が前記許容閾値未満である場合には前記渋滞に関する通知を行わないように構成されている自動運行装置。

【請求項10】

請求項１から９の何れか１項に記載の自動運行装置であって、
前記渋滞情報取得部は、前記渋滞の原因を取得し、
前記渋滞通知処理部は、前記渋滞の原因が事故であるか否かに応じて当該渋滞に関する通知タイミング又は通知時に前記運転席乗員に与える刺激の強度を変更するように構成されている自動運行装置。

【請求項11】

請求項１から１０の何れか１項に記載の自動運行装置であって、
前記渋滞通知処理部は、前記自動運転が実行されていない場合は、所定の態様で前記渋滞に関する通知を実施するか、又は、前記渋滞の詳細情報を含まない通知は実施しないように構成されている自動運行装置。

【請求項12】

請求項１から１１の何れか１項に記載の自動運行装置であって、
前記渋滞に関する通知は、経路変更するか否かの選択をドライバに要求することを含み、
前記渋滞通知処理部は、前記渋滞に関する通知に対して、ドライバによって経路変更しないことが選択された場合には、通知済みの前記渋滞とは別の渋滞に遭遇した場合であっても前記渋滞に関する通知を実施しないように構成されている自動運行装置。

【請求項13】

請求項１２に記載の自動運行装置であって、
前記渋滞情報取得部は、前記渋滞の原因が交通事故であるか否かを取得し、
前記渋滞通知処理部は、前記別の渋滞の原因が前記交通事故である場合には、前回の前記渋滞に対する応答方針として経路変更しないことがドライバによって選択されている場合であっても、前記渋滞に関する通知を実施するように構成されている自動運行装置。

【請求項14】

請求項１から１１の何れか１項に記載の自動運行装置であって、
前記渋滞に関する通知は、当該渋滞に対する応答方針として、経路変更するか否かの選択をドライバに要求することを含み、
前記渋滞通知処理部は、離脱済みの前記渋滞とは別の渋滞である新規渋滞に遭遇した際、渋滞の理由が交通事故であるか否かに応じて、前記離脱済みの渋滞に対してドライバが指示した前記応答方針を、前記新規渋滞への応答方針として自動的に適用するか否かを変更するように構成されている自動運行装置。

【請求項15】

請求項１から７の何れか１項に記載の自動運行装置であって、
前記乗員状態取得部は、前記運転席乗員が眠っている時間である睡眠継続時間を取得し、
前記渋滞通知処理部は、
入力装置からの信号又は予め登録されているデータに基づいて、前記運転席乗員が希望する睡眠時間である睡眠希望時間を取得し、
前記運転席乗員が睡眠中に渋滞に遭遇しても、前記睡眠継続時間が前記睡眠希望時間未満である場合には、前記渋滞に関する通知を実施しないように構成されている自動運行装置。

【請求項16】

少なくとも１つのプロセッサを備える、請求項１から７、及び１５の何れか１項に記載の自動運行装置であって、
前記プロセッサは、
前記渋滞情報取得部、前記渋滞通知処理部、及び前記乗員状態取得部としての処理を実行するとともに、
前記乗員状態センサからの入力信号に基づき、前記運転席乗員の体調が良好であるか否かを判断し、
前記運転席乗員の体調が不調であると判断した場合には、前記自動運転を実施中であることを条件として、眠ることを提案し、
前記提案後に前記運転席乗員が睡眠状態に移行した場合には、前記運転席乗員が入眠してから所定時間は前記渋滞に関する通知を実施しないように構成されている自動運行装置。

【請求項17】

少なくとも１つのプロセッサを備える、請求項１から７、１５、及び１６の何れか１項に記載の自動運行装置であって、
前記プロセッサは、
前記渋滞情報取得部、前記渋滞通知処理部、及び前記乗員状態取得部としての処理を実行するとともに、
前記運転席乗員が眠っている間に前記渋滞に遭遇した結果として、前記自動運転の開始時に想定されていなかった通知対象事象が発生した場合には、前記運転席乗員を覚醒させるための処理を実行するように構成されており、
前記通知対象事象は、自車両が走行するためのエネルギーの残量の低下、又は、自動運転を終了させうる環境要素の発生を含む、自動運行装置。

【請求項18】

少なくとも１つのプロセッサを備える、請求項１から７及び１５から１７の何れか１項に記載の自動運行装置であって、
前記プロセッサは、
前記渋滞情報取得部、前記渋滞通知処理部、及び前記乗員状態取得部としての処理を実行するとともに、
自車両が走行するためのエネルギーの残量を検出するセンサから、前記エネルギーの残量を取得し、
前記運転席乗員が眠っている間に前記渋滞に遭遇した場合、当該渋滞の影響によって前記エネルギーが不足する可能性があるか否かを判断し、
前記エネルギーが不足する可能性がある場合には、前記運転席乗員を覚醒させるための処理を実行するように構成されている自動運行装置。

【請求項19】

運転席に着座している乗員である運転席乗員の睡眠を許容する自動化レベルでの自動運転を実施可能な自動運行装置と接続されて使用される通知制御装置であって、
自車両の走行経路上の渋滞にかかる情報を取得する渋滞情報取得部（Ｆ２１）と、
報知デバイス（２１、２２）を介して前記運転席乗員へ前記渋滞に係る情報を通知するための処理を実施する渋滞通知処理部（Ｆ６１）と、
前記運転席乗員の状態をセンシングする乗員状態センサ（１６）からの入力信号に基づき、前記運転席乗員の睡眠状態を取得する乗員状態取得部（Ｆ３）と、
前記自動運行装置から前記自動運転を実行中であるか否かを示す信号を取得する運転モード取得部（Ｆ７）と、を備え、
前記渋滞通知処理部は、前記自動運転が実行されている間は、前記運転席乗員が眠っているか否かに応じて、前記渋滞に関する通知の態様を変更する通知制御装置。

【請求項20】

車両で使用される少なくとも１つのプロセッサ（３１、２４１）によって実施される通知制御方法であって、
外部装置からの受信データ又は前記車両に搭載された周辺監視センサの検出結果に基づき、前記車両の走行経路上の渋滞にかかる情報を取得することと、
報知デバイス（２１、２２）を介して、運転席に着座している乗員である運転席乗員に前記渋滞に係る情報を通知するための処理を実施することと、
前記運転席乗員の状態をセンシングする乗員状態センサ（１６）からの入力信号に基づき、前記運転席乗員が眠っているか否かを含む乗員状態情報を取得することと、
前記運転席乗員の睡眠を許容する自動化レベルでの自動運転を実施可能に構成されている自動運行装置から前記自動運転を実行中であるか否かを示す信号を取得することと、
前記自動運転が実行されている間は、前記運転席乗員が眠っているか否かに応じて、前記渋滞に関する通知の態様を変更することと、を含む通知制御方法。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、ドライバの睡眠が許容される自動運転を実施可能な自動運行装置に関する。

【背景技術】

【0002】

特許文献１には、運転席乗員が睡眠している間も、車載システムによる車両の自律的な走行制御（いわゆる自動運転）を継続する制御装置が開示されている。

【0003】

なお、運転操作の自動化レベルとしては、例えば米国自動車技術会（SAE International、SAEは登録商標）が定義しているレベル０～５が知られている。レベル０は、システムが介入せずに運転席の乗員（いわゆるドライバ）が全ての運転タスクを実施するレベルである。レベル０は、いわゆる手動運転に相当する。レベル１は、操舵と加減速との何れかをシステムが支援するレベルである。レベル２は、システムが操舵と加減速との両方を支援するレベルである。自動化レベル１～２では、安全運転のための周辺監視義務が運転席乗員に生じる。レベル３は、高速道路等の特定の場所ではシステムが全ての運転タスクを実施可能であり、緊急時に運転席乗員が運転操作を行うレベルである。レベル４は、対応不可能な道路、極限環境等の特定状況下を除き、システムが全ての運転タスクを実施可能なレベルである。レベル５は、全ての環境下でシステムが全ての運転タスクを実施するレベルである。

【0004】

自動化レベル３以上がいわゆる自動運転に相当する。レベル３では例えば睡眠など、運転席乗員がすぐに運転操作に復帰できない状態に移行することは禁止される。レベル４やレベル５が、運転席乗員の睡眠が許容される自動化レベルに相当する。本開示では、レベル３相当の自動運転をレベル３自動運転と称するとともに、レベル４以上の自動運転をレベル４自動運転とも称する。

【先行技術文献】

【特許文献】

【0005】

【文献】特開２０２１－６８０２号公報

【発明の概要】

【発明が解決しようとする課題】

【0006】

レベル３自動運転では運転席乗員は起き続けている必要がある。そのため、運転席乗員は渋滞に巻き込まれたかどうかを認識しやすい。それに伴い、到着予定時間に遅れが生じそうかどうかも認識しうる。一方、レベル４自動運転では、運転席乗員の睡眠が許容される。そして、レベル４自動運転では運転席乗員が睡眠中も車両は目的地までのルートに従って自律的な走行を続ける。レベル４自動運転の実行中でかつ運転席乗員が眠っている状況下で渋滞が発生した場合、運転席乗員は渋滞の発生を認識することは困難である。レベル４自動運転の実行中でかつ運転席乗員が眠っている状況下で渋滞が発生した場合、運転席乗員は、自然と眠りから覚めたタイミングで初めて走行スケジュールが遅れていることに気づく。その結果、自動運転機能に対する利便性が損なわれうる。

【0007】

特許文献１には、レベル４自動運転の実行中に渋滞を検知した場合に、睡眠中の運転席乗員に対してその旨を通知することは開示されていない。よって、特許文献１に開示の構成では、睡眠中の運転席乗員が渋滞に巻き込まれたことを認識することは難しい。また、上記懸念に対する想定構成としては、渋滞の発生を検知するたびに運転席乗員に通知する構成が考えられるが、渋滞が発生するたびに通知を行うと運転席乗員に煩わしさを与える可能性がある。

【0008】

本開示は、上記の検討又は着眼点に基づいて成されたものであり、その目的の１つは、自動運転中の渋滞によって乗員の利便性又は快適性が損なわれる恐れを低減可能な自動運行装置、通知制御装置、車両制御方法を提供することにある。

【課題を解決するための手段】

【0009】

ここに開示される第１の自動運行装置は、運転席に着座している人物である運転席乗員の睡眠を許容する自動化レベルでの自動運転を実施可能な自動運行装置であって、自車両の走行経路上の渋滞にかかる情報を取得する渋滞情報取得部（Ｆ２１）と、報知デバイス（２１、２２）を介して運転席乗員へ渋滞に係る情報を通知するための処理を実施する渋滞通知処理部（Ｆ６１）と、運転席乗員の状態をセンシングする乗員状態センサ（１６）からの入力信号に基づき、運転席乗員が眠っているか否かを取得する乗員状態取得部（Ｆ３）と、を備え、渋滞通知処理部は、自動運転が実行されている間は、運転席乗員が眠っているか否かに応じて、渋滞に関する通知の態様を変更する。

【0010】

上記構成によれば、自動運転中は、運転席乗員が起きているか否かに応じて、渋滞に関する通知態様が変更される。当該構成によれば、渋滞に関する通知の態様として、運転席乗員の状態に応じた態様が選択可能となるため、一律的に通知を実施する構成や通知を実施しない構成に比べて、運転席乗員に煩わしさを与える可能性を抑制できる。また、上記の構成によれば、運転席乗員が寝ている場合も、所定の態様で渋滞に関する通知が実施されうる。仮に通知内容自体は運転席乗員に認識されなくとも、通知による刺激（光や音、振動）によって運転席乗員が覚醒し、その結果として、渋滞に巻き込まれていることを乗員が気づきやすくなる。つまり、運転席乗員が起きたときには当初の到着時刻を過ぎている、あるいは、一定時間以上遅れることが避けられない状況となっている恐れを低減することができる。よって、上記の構成によれば、渋滞によって乗員の利便性又は快適性が損なわれる恐れを低減可能となる。

【0011】

本開示の第２の自動運行装置は、運転席乗員の睡眠を許容する自動化レベルでの自動運転を実施可能な自動運行装置であって、自車両の走行経路上の渋滞にかかる情報を取得する渋滞情報取得部（Ｆ２１）と、報知デバイス（２１、２２）を介して運転席乗員へ渋滞に係る情報を通知するための処理を実施する渋滞通知処理部（Ｆ６１）と、を備え、渋滞情報取得部は、渋滞による到着予定時刻の遅延量である到着遅延量又は渋滞の長さを示す渋滞長を取得し、渋滞通知処理部は、自動運転が実行されている間は、到着遅延量又は渋滞長に応じて、自動運転を実行における渋滞に関する通知の態様を変更する。

【0012】

上記構成によれば、自動運転中は、渋滞長又は到着遅延量に基づいて、渋滞に関する通知態様が変更される。当該構成によれば、渋滞に関する通知の態様として、渋滞の影響度合いに応じた態様が選択可能となるため、一律的に通知を実施する構成や通知を実施しない構成に比べて、運転席乗員に煩わしさを与える可能性を抑制できる。また、上記の構成によれば、仮に運転席乗員が寝ている場合であっても、所定の態様で渋滞に関する通知が実施されうる。通知による刺激（光や音、振動）によって運転席乗員が覚醒した場合には、乗員は視界に入る周辺状況に基づいて渋滞に巻き込まれていることを認識しうる。その結果、運転席乗員が起きたときには当初の到着時刻を過ぎている、あるいは、一定時間以上遅れることが避けられない状況となっている恐れを低減することができる。つまり上記の構成によっても、渋滞によって乗員の利便性又は快適性が損なわれる恐れを低減可能となる。

【0013】

本開示の通知制御装置は、運転席に着座している乗員である運転席乗員の睡眠を許容する自動化レベルでの自動運転を実施可能な自動運行装置と接続されて使用される通知制御装置であって、自車両の走行経路上の渋滞にかかる情報を取得する渋滞情報取得部（Ｆ２１）と、報知デバイス（２１、２２）を介して運転席乗員へ渋滞に係る情報を通知するための処理を実施する渋滞通知処理部（Ｆ６１）と、運転席乗員の状態をセンシングする乗員状態センサ（１６）からの入力信号に基づき、運転席乗員の睡眠状態を取得する乗員状態取得部（Ｆ３）と、自動運行装置から自動運転を実行中であるか否かを示す信号を取得する運転モード取得部（Ｆ７）と、を備え、渋滞通知処理部は、自動運転が実行されている間は、運転席乗員が眠っているか否かに応じて、渋滞に関する通知の態様を変更する。

【0014】

本開示の通知制御方法は、車両で使用される少なくとも１つのプロセッサ（３１、２４１）によって実施される通知制御方法であって、外部装置からの受信データ又は車両に搭載された周辺監視センサの検出結果に基づき、車両の走行経路上の渋滞にかかる情報を取得することと、報知デバイス（２１、２２）を介して、運転席に着座している乗員である運転席乗員に渋滞に係る情報を通知するための処理を実施することと、運転席乗員の状態をセンシングする乗員状態センサ（１６）からの入力信号に基づき、運転席乗員が眠っているか否かを含む乗員状態情報を取得することと、運転席乗員の睡眠を許容する自動化レベルでの自動運転を実施可能に構成されている自動運行装置から自動運転を実行中であるか否かを示す信号を取得することと、自動運転が実行されている間は、運転席乗員が眠っているか否かに応じて、渋滞に関する通知の態様を変更することと、を含む。

【0015】

上記通知制御装置／通知制御方法によれば、第１の自動運行装置と同様の作用により、渋滞によって乗員の利便性又は快適性が損なわれる恐れを低減可能となる。

【0016】

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

【図面の簡単な説明】

【0017】

【図1】自動運転システムの構成を示すブロック図である。

【図2】自動運転ＥＣＵの機能ブロック図である。

【図3】渋滞応答処理の一例を示すフローチャートである。

【図4】渋滞応答処理の他の例を示すフローチャートである。

【図5】睡眠深度と渋滞長に応じた通知態様の設定例を示す図である。

【図6】渋滞応答処理の他の例を示すフローチャートである。

【図7】通過済みの渋滞に対するドライバの指示内容に応じて次回以降の渋滞に対する通知を制御する処理を説明するためのフローチャートである。

【図8】渋滞の理由に応じて通知の実施／不実施を切り替える処理を説明するためのフローチャートである。

【図9】ドライバの体調に応じて睡眠中の通知の実施／不実施を切り替える処理を説明するためのフローチャートである。

【図10】バッテリ残量等の通知に係る制御フローを示す図である。

【図11】自動運転システムの他の構成例を示すブロック図である。

【発明を実施するための形態】

【0018】

図面を参照しながら、本開示の実施形態の一例を説明する。本開示は、以下の自動運転システムＳｙｓが適用される地域の法規及び慣習に適合するように適宜変更して実施可能である。

【0019】

＜前置き＞
図１は、本開示に係る自動運転システムＳｙｓの概略的な構成の一例を示す図である。自動運転システムＳｙｓは、道路上を走行可能な車両に搭載可能である。自動運転システムＳｙｓが適用される車両としては、四輪自動車のほか、二輪自動車、三輪自動車等であってもよい。自動運転システムＳｙｓが適用される車両は、個人によって所有されるオーナーカーであってもよいし、シェアカーや、レンタカーであってもよい。シェアカーは、カーシェアリングサービスに供される車両であり、レンタカーは車両貸し出しサービスに供される車両である。以降では自動運転システムＳｙｓが搭載されている車両を自車両とも記載する。

【0020】

ここでは一例として自車両は電動車とするがこれに限らない。自車両は、エンジン車であってもよい。電動車の概念には、電気自動車のみならず、プラグインハイブリッド車や、ハイブリッド車、燃料電池車を含めることができる。エンジン車は、駆動源としてエンジンのみを備える車両であって、ガソリンや軽油などの燃料によって走行する車両に相当する。電気自動車は、モータのみを駆動源として備える車両を指す。ハイブリッド車は動力源としてエンジンとモータを備える車両を指す。

【0021】

本開示におけるドライバとは、実際に運転操作を実施している人物に限らず、自動運転終了時に自動運転システムＳｙｓから運転操作の権限を受け取るべき人物を指しうる。つまり本開示におけるドライバとは、実際に運転しているか否かに関わらず、運転席に着座している人物、つまり運転席乗員を指す。本開示におけるドライバとの記載は運転席乗員と置き換えることができる。自車両は、車両外部に存在するオペレータによって遠隔操作される遠隔操作車両であってもよい。自動運転システムＳｙｓから運転操作を引き継ぐ人物は、車両外部に存在するオペレータであってもよい。ここでのオペレータとは、車両の外部から遠隔操作によって車両を制御する権限を有する人物を指す。オペレータもまた、運転席乗員の概念に含めることができる。システムによる種々の情報の通知対象はオペレータであってもよい。

【0022】

自動運転システムＳｙｓは、自車両を所定の経路に沿って自律的に走行させる、いわゆる自動運転機能を提供する。運転操作の自動化の度合い（以下、自動化レベル）としては、例えば米国自動車技術会（SAE International）が定義しているように、複数のレベルが存在し得る。自動化レベルは、例えば以下のレベル０～５の６段階に区分される。

【0023】

レベル０は、システムが介入せずにドライバが全ての運転タスクを実施するレベルである。運転タスクには、例えば操舵及び加減速が含まれる。また、運転タスクには、例えば車両前方など、車両の周辺を監視することも含まれる。レベル０は、いわゆる完全手動運転レベルに相当する。レベル１は、操舵と加減速との何れかをシステムがサポートするレベルである。レベル２は、操舵操作と加減速操作のうちの複数をシステムがサポートするレベルを指す。レベル１～２は、いわゆる運転支援レベルに相当する。

【0024】

レベル３は、運行設計領域（ＯＤＤ：Operational Design Domain）内においてシステムが全ての運転タスクを実行する一方、緊急時にはシステムからドライバに操作権限が移譲されるレベルを指す。ＯＤＤは、例えば走行位置が自動車専用道路内であること等の、自動運転を実行可能な条件規定するものである。レベル３は、いわゆる条件付き自動運転に相当する。

【0025】

レベル４は、対応不可能な所定の道路、極限環境等の特定状況下を除き、システムが全ての運転タスクを実施するレベルである。レベル４は、ＯＤＤ内にてシステムが全ての運転タスクを実施するレベルに相当する。レベル４は、いわゆる高度自動運転に相当する。レベル５は、あらゆる環境下でシステムが全ての運転タスクを実施可能なレベルである。レベル５は、いわゆる完全自動運転に相当する。

【0026】

自動化レベル３～５が自動運転に相当する。本開示では自動化レベル４に相当する自動運転をレベル４自動運転と称する。また、自動化レベル３に相当する自動運転をレベル３自動運転と称する。レベル３自動運転では、ドライバは緊急時には速やかに運転操作を再開する必要があり、睡眠などは禁止される。一方、レベル４自動運転では、ドライバは睡眠が許容されうる。本開示の自動運転システムＳｙｓはレベル４自動運転を実施可能に構成されている。もちろん、本開示の自動運転システムＳｙｓは、自動化レベル５に相当する自動運転を実施可能に構成されていても良い。

【0027】

以下で述べる車両の運転席は一例として、背もたれ部が例えば乗員の睡眠又は休憩に適した角度まで倒すことが可能なリクライニングシートとして構成されている。本開示では一例として背もたれ部の角度は車両の床部を基準として表現する。乗員の睡眠又は休憩に適した角度とは例えば、３０度又は４５度などである。もちろん、運転席は、背もたれ部が０度まで傾斜可能に構成されていてもよい。運転席の背もたれ部が車両の床部／着座面に対してなす角度を背もたれ角とも記載する。背もたれ角が小さいほど背もたれ部が車両後方に倒れていることになる。本開示では、背もたれ角が４５度以下となっている状態を休憩姿勢とも称する。なお、他の態様として、背もたれ角は車両高さ方向を基準として表現されてもよい。高さ方向を０°として表現される背もたれ部の角度はリクライニング角とも呼ばれうる。

【0028】

＜自動運転システムＳｙｓの全体構成について＞
自動運転システムＳｙｓは一例として図１に示す種々の構成を備える。すなわち、自動運転システムＳｙｓは、周辺監視センサ１１、車両状態センサ１２、ロケータ１３、地図記憶部１４、無線通信機１５、乗員状態センサ１６、ボディＥＣＵ１７、及び走行アクチュエータ１８を備える。また、自動運転システムＳｙｓは、車載ＨＭＩ２０、及び自動運転ＥＣＵ３０を備える。なお、ＥＣＵは、Electronic Control Unitの略であり、電子制御装置を意味する。ＨＭＩは、ヒューマンマシンインターフェース（Human Machine Interface）の略である。

【0029】

自動運転ＥＣＵ３０は、周辺監視センサ１１などといった上記装置／センサのそれぞれと車両内ネットワークＩｖＮを介して又は専用の信号線によって相互通信可能に接続されている。車両内ネットワークＩｖＮは、車両内に構築されている通信ネットワークである。車両内ネットワークＩｖＮの規格としては、Controller Area Network（以降、ＣＡＮ：登録商標）や、Ethernet（登録商標）など、多様な規格を採用可能である。装置同士の接続形態は適宜変更可能である。一部の装置／センサは自動運転ＥＣＵ３０と専用の信号線によって直接的に接続されていてもよい。

【0030】

周辺監視センサ１１は、自車両の周辺環境を監視する自律センサである。周辺監視センサ１１は、自車両周囲の検出範囲から予め規定された移動物体及び静止物体を検出可能である。自動運転システムＳｙｓは、複数種類の周辺監視センサ１１を備えうる。自動運転システムＳｙｓは例えば周辺監視センサ１１として、カメラ１１１及びミリ波レーダ１１２を備える。

【0031】

カメラ１１１は、例えば車両前方を所定の画角で撮像するように配置された、いわゆる前方カメラである。カメラ１１１は、フロントガラスの車室内側の上端部や、フロントグリル、ルーフトップ等に配置されている。カメラ１１１は、画像フレームを生成するカメラ本体部に加えて、画像フレームをもとに所定の検出対象物を検出するカメラＥＣＵを含みうる。カメラ本体部は少なくともイメージセンサとレンズとを含む構成である。カメラＥＣＵは、ＣＰＵ（Central Processing Unit）や、ＧＰＵ（Graphics Processing Unit）などを主体として構成されている。カメラＥＣＵは、例えばディープラーニングを適用した識別器を用いて検出対象として登録されている物体を検出及び識別する。なお、ディープラーニングの手法としてはＣＮＮ（Convolutional Neural Network）やＤＮＮ（Deep Neural Network）などを採用することできる。

【0032】

カメラ１１１は、例えば、歩行者や他車両などの移動体を検出する。また、カメラ１１１は、道路端や、路面標示、道路沿いに設置される構造物といった地物も検出しうる。路面標示とは、レーンの境界を示す車線区画線や、横断歩道、停止線、導流帯、安全地帯、規制矢印などである。道路沿いに設置される構造物とは、道路標識、ガードレール、縁石、電柱、信号機などである。カメラ１１１は、その他、前方車両のハザードランプや方向指示器といった灯火装置の点灯状態も検出しうる。

【0033】

自動運転システムＳｙｓは複数のカメラ１１１を備えうる。例えば自動運転システムＳｙｓは、カメラ１１１として、前方カメラの他に、車両側方を撮像する側方カメラや、車両後方を撮像する後方カメラを備えていても良い。なお、カメラ画像を解析することで検出対象物体を検出する機能は、例えば自動運転ＥＣＵ３０など他のＥＣＵが備えていても良い。自動運転システムＳｙｓ内における機能配置は適宜変更可能である。カメラ１１１は、自車周囲を撮影した撮像データ及び撮像データの解析結果の少なくとも一方を、車両内ネットワークＩｖＮに出力する。車両内ネットワークＩｖＮに流れるデータは適宜自動運転ＥＣＵ３０によって参照される。

【0034】

ミリ波レーダ１１２は、所定方向に向けてミリ波又は準ミリ波といった探査波を送受信することにより、自車両に対する物体の相対位置や相対速度を検出するデバイスである。自動運転システムＳｙｓはそれぞれ検出エリアが相違するように配置された複数のミリ波レーダ１１２を備えうる。自動運転システムＳｙｓは、ミリ波レーダ１１２として前方ミリ波レーダ及び後方ミリ波レーダを備える。前方ミリ波レーダは、車両前方に向けて探査波を送信するミリ波レーダ１１２であって、例えば、フロントグリルや、フロントバンパに設置されている。後方ミリ波レーダは、車両後方に向けて探査波を送信するミリ波レーダ１１２であって、例えば、リアバンパに設置されている。各ミリ波レーダ１１２は、検出物の相対位置及び相対速度を示すデータを生成し、検出結果として自動運転ＥＣＵ３０等に出力する。ミリ波レーダ１１２の検出対象物には、他車両や、歩行者などの他、マンホール（鉄板）、ランドマークとしての立体構造物などが含まれうる。

【0035】

自動運転システムＳｙｓは、周辺監視センサ１１として、カメラ１１１及びミリ波レーダ１１２の他、ＬｉＤＡＲ、ソナー等を備えていてもよい。ＬｉＤＡＲは、Light Detection and Ranging、又は、Laser Imaging Detection and Rangingの略である。ＬｉＤＡＲは、レーザ光を照射することによって、検出方向ごとの反射点の位置を示す３次元点群データを生成するデバイスである。ＬｉＤＡＲはレーザレーダとも称される。ソナーは探査波としての超音波を送受信することで反射物の相対位置や相対速度を検出するデバイスである。ＬｉＤＡＲやソナーに関しても、自動運転システムＳｙｓはそれぞれ複数個備えていても良い。なお、カメラ１１１及びミリ波レーダ１１２は周辺監視センサ１１の一例であり、必須の要素ではない。各周辺監視センサ１１の検出結果は自動運転ＥＣＵ３０に入力される。

【0036】

車両状態センサ１２は、自車両の状態に関する情報を検出するセンサ群である。車両状態センサ１２には、車速センサ、操舵角センサ、加速度センサ、ヨーレートセンサ等が含まれる。車速センサは、自車の車速を検出する。操舵角センサは、操舵角を検出する。加速度センサは、自車の前後加速度、横加速度等の加速度を検出する。ヨーレートセンサは、自車の角速度を検出する。車両状態センサ１２は、検出対象とする物理状態量の現在の値（つまり検出結果）を示すデータを車両内ネットワークＩｖＮに出力する。

【0037】

車両状態センサ１２として自動運転システムＳｙｓが使用するセンサの種類は適宜設計されればよく、上述した全てのセンサを備えている必要はない。また、自動運転システムＳｙｓは車両状態センサ１２として背もたれ角センサなどを備えていても良い。背もたれ角センサは、運転席の背もたれ角を検出するセンサである。自動運転ＥＣＵ３０には、背もたれ角センサ、又は運転席に設けられたシートモータから、運転席の背もたれ角を示す信号が入力されてもよい。

【0038】

ロケータ１３は、ＧＮＳＳ（Global Navigation Satellite System）を構成する測位衛星から送信される航法信号を用いて自車両の位置座標を算出及び出力するデバイスである。ロケータ１３は、ＧＮＳＳ受信機及び慣性センサ等を含む。ロケータ１３は、ＧＮＳＳ受信機で受信する測位信号、慣性センサの計測結果、及び車両内ネットワークＩｖＮに流れる車速情報等を組み合わせ、自車両の自車位置及び進行方向等を逐次算出し、ロケータ情報として自動運転ＥＣＵ３０に向けて出力する。

【0039】

地図記憶部１４は、自動運転制御に必要な道路情報を含む、いわゆるＨＤ（High Definition）マップのデータが保存されている記憶装置である。地図記憶部１４に保存されている地図データは、道路の３次元形状や、レーン区画線などの路面標示の設置位置、交通標識の設置位置等が、自動運転等に必要な精度で含んでいる。

【0040】

地図記憶部１４に保存される地図データは、例えば無線通信機１５が地図サーバなどから受信したデータによって更新されうる。地図サーバは車両外部に配置された、地図データを配信するサーバである。地図記憶部１４は、無線通信機１５が地図サーバから受信した地図データを、データの有効期限が切れるまで一時的に保持するための記憶装置であっても良い。地図記憶部１４は自動運転ＥＣＵ３０又はロケータ１３に内蔵されていても良い。地図記憶部１４が保持する地図データは、合流地点や信号機、ランドマーク等の地物データを含むことを条件として、ナビゲーション用の地図データであるナビ地図データであっても良い。

【0041】

無線通信機１５は、自車両が他の装置と無線通信を実施するための装置である。無線通信機１５は、セルラー通信を実施可能に構成されている。セルラー通信とは、所定の広域無線通信規格に準拠した無線通信である。ここでの広域無線通信規格としては例えばＬＴＥ（Long Term Evolution）や４Ｇ、５Ｇなど多様なものを採用可能である。

【0042】

自車両は、無線通信機１５の搭載により、インターネットに接続可能なコネクテッドカーとなる。例えば自動運転ＥＣＵ３０は、無線通信機１５との協働により、地図配信サーバから現在位置に応じた地図データをダウンロードして利用可能となる。なお、無線通信機１５は、広域無線通信規格に準拠した方式によって、無線基地局を介さずに、他の装置との直接的に無線通信を実施可能に構成されていても良い。つまり、無線通信機１５は、セルラーＶ２Ｘ（ＰＣ５／Ｕｕ）を実施するように構成されていても良い。

【0043】

また、無線通信機１５は、狭域通信を実施可能に構成されている。本開示における狭域通信とは、通信可能距離が数百ｍ以内に限定される無線通信を指す。狭域通信の規格としては、例えばＩＥＥＥ８０２．１１ｐ規格に対応するＤＳＲＣ（Dedicated Short Range Communications）や、Ｗｉ－Ｆｉ（登録商標）などを採用可能である。狭域通信方式は、前述のセルラーＶ２Ｘであってもよい。無線通信機１５はセルラー通信と狭域通信の何れか一方のみを実施可能に構成されていてもよい。無線通信機１５はＢＬＥ（Bluetooth Low Energy、Bluetoothは登録商標）などの規格に準拠した通信を実施可能に構成されていても良い。

【0044】

無線通信機１５は、地図サーバや、交通情報センタ、路側機、他車両といった外部装置から、自車両の走行経路に係る動的地図データを受信しうる。路側機は道路沿いに設置された無線通信設備である。動的地図データとは、例えば存続状態や位置が１０分から１時間単位で変化しうる要素についてのデータである。渋滞区間や規制区間、工事区間などの位置情報、地点ごとの路面状態、天候、落下物、巡航速度などが動的な地図要素に該当する。動的な地図要素についてのデータは、静的地図データとともに地図サーバからストリーミング配信の態様にて受信しても良い。

【0045】

このように無線通信機１５は、外部装置から、渋滞情報を取得する。渋滞情報は、渋滞区間の位置、及びその長さを示す渋滞長の少なくとも何れか一方を含む。例えば渋滞長は、例えば１ｋｍといった距離の概念で表現される。なお、渋滞長は、渋滞区間に進入してから退出するまでに要する時間である通過所要時間で表現されていても良い。渋滞長は、渋滞区間の開始位置及び終了位置によって間接的に表現されても良い。渋滞情報は、渋滞の原因や、渋滞中の平均速度などを含んでいても良い。無線通信機１５が取得した渋滞情報は、自動運転ＥＣＵ３０に転送される。

【0046】

なお、本開示での渋滞とは、例えば、走行速度が所定の渋滞判定値以下となっている状態、又は、停止発進を繰り返す車列が１ｋｍ以上かつ１５分以上継続した状態とすることができる。渋滞判定値は、例えば４０ｋｍ／ｈである。もちろん渋滞判定値は２０ｋｍ／ｈや６０ｋｍ／ｈであっても良い。渋滞判定値は、道路ごとに設定されている制限速度に応じて動的に決定されても良い。渋滞判定値は、制限速度の４分の１などに設定されても良い。渋滞判定値は、自動車専用道路か、一般道かで異なる値が適用されても良い。自動車専用道路用の渋滞判定値は２０ｋｍ／ｈとする一方、一般道路用の渋滞判定値は１０ｋｍ／ｈであっても良い。ここでの自動車専用道路とは、歩行者や自転車の進入が禁止されている道路であって、例えば高速道路などの有料道路などを指す。

【0047】

無線通信機１５は、車車間通信により前方車両からハザードランプの点灯状態や、車速、ブレーキペダルの踏み込み度合いなどを取得しても良い。また、前方車両との車車間通信により、前方車両において渋滞状態が検知されているか否かを取得してもよい。ここでの前方車両とは、自車両の前方を走行する車両を指す。前方車両には、主として自車両と同一のレーンを走行する車両に限らず、隣接レーンを走行する車両を含める事ができる。前方車両の概念には、斜め前方を走行している車両を含めることができる。自車両の前方に存在する車両の中で、自車両と同一のレーンを走行し、且つ、自車両から最も近い車両を先行車両とも記載する。

【0048】

乗員状態センサ１６は、ドライバの状態を検出するセンサである。自動運転システムＳｙｓは複数種類の乗員状態センサ１６を備えうる。例えば自動運転システムＳｙｓは、例えば、ドライバステータスモニタ（以降、ＤＳＭ：Driver Status Monitor）を備える。ＤＳＭは、ドライバの顔画像に基づいてドライバの状態を逐次検出するセンサである。具体的には、ＤＳＭは、近赤外カメラを用いてドライバの顔部を撮影し、その撮像画像に対して画像認識処理を施すことで、ドライバの顔の向きや視線方向、瞼の開き度合い等を逐次検出する。ＤＳＭの赤外線カメラは、ドライバの顔を撮影可能なように、例えば運転席のヘッドレスト部に光軸を向けた姿勢にて、ステアリングコラムカバーの上面や、インストゥルメントパネルの上面、フロントガラスの上端部等に配置されている。

【0049】

乗員状態センサ１６としてのＤＳＭは、撮影画像から特定したドライバの顔の向きや、視線方向、瞼の開き度合い等を示す情報をドライバ状態データとして車両内ネットワークＩｖＮへ逐次出力する。ドライバ状態データが乗員状態情報に相当する。なお、ＤＳＭを構成するカメラは可視光カメラであってもよい。ＤＳＭを構成するカメラは、仰向きで寝ているドライバの顔部を撮像可能なように、オーバーヘッドコンソールや、天井の中央部などに設けられていても良い。ＤＳＭを構成するカメラは複数あってもよい。自動運転システムＳｙｓは、ＤＳＭの他に、助手席や後部座席の乗員（つまり同乗者）の有無及びその状態を検出するカメラを備えていても良い。また、カメラの映像信号に基づきドライバ等の状態を検出する機能は、例えば自動運転ＥＣＵ３０が備えていても良い。助手席等の有無及びその状態を検出するカメラを同乗者センサと称する。同乗者センサは乗員状態センサの一種に相当する。また、同乗者の有無及び同乗者の状態を示すデータもまた、上院状態情報に相当する。

【0050】

自動運転システムＳｙｓは、乗員状態センサ１６として、ＤＳＭの代わりに／並列的に、ＤＳＭ以外の生体センサを備えていても良い。例えば自動運転システムＳｙｓは乗員状態センサ１６として、心拍センサや、脈波センサ、体温センサなどを備えていても良い。心拍センサ等は、運転席の背もたれ部やヘッドレストに内蔵されていても良いし、ステアリングに設けられていても良い。また、探査波としてのミリ波を運転席に向けて送受信することで、ドライバの心拍数や体動、姿勢を検出するミリ波レーダも生体センサに含めることができる。

【0051】

乗員状態センサ１６は、ドライバの例えば手首等に装着されて使用されるウェアラブルデバイスであっていてもよい。ウェアラブルデバイスは、リストバンド型、腕時計型、指輪型、イヤホン型など、多様な形状のものを採用可能である。乗員状態センサ１６としてのウェアラブルデバイスは、例えば無線通信機１５を介して自動運転ＥＣＵ３０と相互通信可能に構成されている。ウェアラブルデバイスと自動運転ＥＣＵ３０との接続態様はＢＬＥなどを用いた無線接続であってもよいし、有線接続であっても良い。

【0052】

ボディＥＣＵ１７は、車両に搭載されたボディ系の車載機器を統合的に制御するＥＣＵである。ボディ系の車載機器には、ヘッドライトなどの灯火装置、シートモータなどが含まれる。シートモータは、運転席としての座席の前後位置や高さ、背もたれ角を変更するモータである。ボディＥＣＵ１７は、シートモータからの入力信号をもとに、現在の背もたれ角などを示す信号を自動運転ＥＣＵ３０に向けて出力してもよい。

【0053】

車載ＨＭＩ２０は、乗員と自動運転システムＳｙｓとが情報をやり取りするためのインターフェース群である。車載ＨＭＩ２０は、ドライバへ向けて情報を通知するためのデバイスである報知デバイスとして、ディスプレイ２１、及びスピーカ２２を備える。また、車載ＨＭＩ２０は、乗員からの操作を受け付ける入力インターフェースとしての入力装置２３を含む。

【0054】

自動運転システムＳｙｓは、ディスプレイ２１として、ヘッドアップディスプレイ（ＨＵＤ：Head-Up Display）、メータディスプレイ、及びセンターディスプレイのうちの１つ又は複数を備える。ＨＵＤは、フロントガラスの所定領域に画像光を投影することにより、ドライバによって知覚されうる虚像を映し出す装置である。メータディスプレイはインストゥルメントパネルにおいて運転席の正面に位置する領域に配置されたディスプレイである。センターディスプレイはインストゥルメントパネルの車幅方向中央部に設けられたディスプレイである。メータディスプレイ及びセンターディスプレイは、液晶ディスプレイや有機ＥＬディスプレイを用いて実現されうる。ディスプレイ２１は自動運転ＥＣＵ３０から入力される制御信号及び映像信号に基づき、入力信号に応じた画像を表示する。

【0055】

スピーカ２２は、自動運転ＥＣＵ３０から入力される信号に対応する音を出力する装置である。音との表現には、通知音のほか、音声や音楽などが含まれる。なお、自動運転システムＳｙｓは、報知デバイスとして、バイブレータやアンビエントライトなどを備えても良い。バイブレータは、ドライバに振動刺激を印加するためのデバイスであって、運転席の背もたれ部やシートベルトに設けられている。なお、バイブレータは、シートベルト自体を振動させることでドライバに振動刺激を印加させるデバイスであっても良い。アンビエントライトは、複数のＬＥＤ（light emitting diode）によって実現される、発光色や発光強度を調停可能な照明装置であって、インストゥルメントパネル及びステアリングホイール等に設けられている。

【0056】

入力装置２３は、自動運転システムＳｙｓに対するドライバの指示操作を受け付けるための装置である。入力装置２３としては、ステアリングホイールのスポーク部に設けられたステアリングスイッチや、ステアリングコラム部に設けられた操作レバー、センターディスプレイに積層されたタッチパネルなどを採用可能である。自動運転システムＳｙｓは、上述した複数種類のデバイスを入力装置２３として備えていても良い。入力装置２３は、ドライバの操作に対応する電気信号を操作信号として車両内ネットワークＩｖＮに出力する。操作信号は、ドライバの操作内容を示す情報を含む。自動運転システムＳｙｓは、入力装置２３を介してレベル４自動運転の開始及び終了にかかる指示を受け付ける。自動運転の開始／終了指示は音声入力によって実施可能に構成されていても良い。マイクなどの音声入力にかかるデバイスも入力装置２３に含めることができる。なお、車載ＨＭＩ２０と自動運転ＥＣＵ３０との間には、例えばＨＣＵ（HMI Control Unit）が介在していても良い。ＨＣＵは、ドライバへの情報通知を統合的に制御する装置である。

【0057】

自動運転ＥＣＵ３０は、周辺監視センサ１１の検出結果などをもとに走行アクチュエータ１８を制御することにより、運転操作の一部又は全部をドライバの代わりに実行するＥＣＵである。自動運転ＥＣＵ３０は自動運行装置とも称される。走行アクチュエータ１８には例えば制動装置としてのブレーキアクチュエータや、電子スロットル、操舵アクチュエータなどが含まれる。操舵アクチュエータには、ＥＰＳ（Electric Power Steering）モータが含まれる。なお、自動運転ＥＣＵ３０と走行アクチュエータ１８との間には、操舵制御を行う操舵ＥＣＵや、加減速制御を行うパワーユニット制御ＥＣＵ、及びブレーキＥＣＵ等、他のＥＣＵが介在していてもよい。

【0058】

自動運転ＥＣＵ３０は、プロセッサ３１、メモリ３２、ストレージ３３、通信インターフェース３４、及びこれらを接続するバス等を備えたコンピュータを主体として構成されている。メモリ３２は書き換え可能な揮発性の記憶媒体であって例えばＲＡＭ（Random Access Memory）である。ストレージ３３は、例えばフラッシュメモリなどの書き換え可能な不揮発性である。ストレージ３３には、プロセッサ３１によって実行されるプログラムである車両制御プログラムが格納されている。車両制御プログラムには、ドライバへの情報の通知態様を制御する通知制御プログラムも含まれる。プロセッサ３１が車両制御プログラムを実行することは、通知制御方法が実行されることに相当する。運転支援にかかる処理を実行するプロセッサは、自動運転にかかる処理を実行するプロセッサとは別に設けられていても良い。自動運転ＥＣＵ３０は複数のプロセッサ３１を備えうる。

【0059】

自動運転ＥＣＵ３０は、自動化レベルが異なる複数の動作モードを備える。ここでは一例として自動運転ＥＣＵ３０は、完全手動モード、運転支援モード、及び自動運転モードを切替可能に構成されている。各動作モードは、ドライバが担当する運転タスクの範囲、換言すればシステムが介入する運転タスクの範囲が異なる。ここでのシステムとは、自動運転システムＳｙｓ、実態的には自動運転ＥＣＵ３０を指す。動作モードは運転モードと言い換えることもできる。

【0060】

完全手動モードは、ドライバがすべての運転タスクを実行する動作モードである。完全手動モードは自動化レベル０に相当する。運転支援モードは、システムが加減速及び操舵操作の少なくとも何れか一方をシステムが実行する動作モードである。運転支援モードの操舵操作の実行主体はドライバであって、少なくともドライバは車両前方などの周辺を監視する必要があるモードである。完全手動モード及び運転支援モードは、ドライバが少なくとも一部の運転タスクを実行する運転モードである。そのため本開示では、完全手動モード及び運転支援モードを区別しない場合には乗員関与モードとも記載する。乗員関与モードは、自動運転モードの対義語としての手動運転モードと呼ぶこともできる。

【0061】

自動運転モードは、システムがすべての運転タスクを実行する動作モードである。ここでは一例として自動運転モードは、自動化レベル４に相当する制御を実行する動作モードとする。なお、自動運転モードは、レベル５の自動運転を実施するものであっても良い。自動運転モードは、ドライバの睡眠が許容される動作モードに相当する。手動運転モードから自動運転モードへは、入力装置２３から入力される操作信号に基づいて切り替えられうる。

【0062】

自動運転モードにおいては、自動運転ＥＣＵ３０は、ドライバによって設定された目的地まで、道路に沿って自車両が走行するように、車両の操舵、加速、減速（換言すれば制動）等を自動で実施する。なお、自動運転モードは、ドライバ操作（いわゆるオーバーライド）の他、システム限界や、ＯＤＤの退出等に起因して終了される。自動運転ＥＣＵ３０は、目的地へ向かう走行経路上の途中に設定される権限移譲予定地点まで自動運転を実施する装置であっても良い。権限移譲予定地点はＯＤＤの退出予定地点に相当する。

【0063】

ＯＤＤとしては、例えば（ａ）走行路が高速道路又は中央分離帯とガードレール等が整った自動車専用道路であること、（ｂ）降雨量が所定の閾値以下であること、（ｃ）全て／所定数以上の周辺監視センサ１１が正常に動作していること等が挙げられる。走行路は、自車両が走行している道路を指す。その他、路上駐車車両が存在しないことなどもＯＤＤに含めることができる。自動運転可能／不可と判定する条件、換言すればＯＤＤを定義する詳細条件は、適宜変更可能である。

【0064】

＜自動運転ＥＣＵ３０の構成について＞
自動運転ＥＣＵ３０は自動運転プログラムを実行することによって実現される、図２に示す機能部を備える。すなわち自動運転ＥＣＵ３０は、情報取得部Ｆ１、環境認識部Ｆ２、乗員状態取得部Ｆ３、モード制御部Ｆ４、計画部Ｆ５、及び制御実行部Ｆ６を有する。

【0065】

情報取得部Ｆ１は、自動運転及び運転支援といった車両制御を実施するための多様な情報を取得する構成である。本開示における「取得」には、他の装置／センサから入力されたデータなどを元に内部演算によって生成／検出することも含まれる。システム内の機能配置は適宜変更であるためである。

【0066】

例えば情報取得部Ｆ１は、カメラ１１１を含む種々の周辺監視センサ１１から検出結果（つまり、センシング情報）を取得する。センシング情報には、自車両周辺に存在する他の移動体や、地物、障害物などの位置や、移動速度、種別などが含まれる。また、情報取得部Ｆ１は、車両状態センサ１２から、自車両の走行速度や加速度、ヨーレート、外部照度などを取得する。さらに、情報取得部Ｆ１は、ロケータ１３から自車位置情報、及び、道路構造にかかる周辺地図情報を取得する。

【0067】

情報取得部Ｆ１は、無線通信機１５との協働により、前方車両から車車間通信にて送信されてきた車両情報を取得しうる。車両情報には、ハザードランプの点灯状態や、ブレーキ踏込の有無／踏込量、加速度、走行速度、位置情報などが含まれうる。情報取得部Ｆ１は、無線通信機１５との協働により、自車両が所定時間以内に通過予定の道路区間についての動的地図データを取得する。ここでの動的地図データは、渋滞情報が含まれる。

【0068】

情報取得部Ｆ１は、入力装置２３からの信号に基づき、自動運転システムＳｙｓに対するドライバの操作なども取得する。例えば情報取得部Ｆ１は、自動運転の開始及び終了にかかる操作信号を入力装置２３から取得する。

【0069】

情報取得部Ｆ１は、乗員状態センサ１６から、ドライバの状態を判断するための情報（つまり判断材料）を取得する。ドライバの状態判断に利用可能な情報としては、例えば、脈拍数、心拍数、呼吸数、体動、目の開度、瞬きの実行頻度、瞬きの実施間隔のばらつき度合い、眼球運動、姿勢、体温、入眠からの経過時間などがある。脈拍数、心拍数、呼吸数などは、１分など、所定時間あたりの実行回数で表現されうる。体動とは寝返りなどの大きな体動である粗体動と、手足や頭部のみの動きによる細かい体動である細体動とに区分されうる。

【0070】

情報取得部Ｆ１が逐次取得する種々の情報は、例えばメモリ３２等の一時記憶媒体に保存され、環境認識部Ｆ２や乗員状態取得部Ｆ３などによって利用される。なお、各種情報は、種別ごとに区分されてメモリに保存されうる。また、各種情報は、例えば最新のデータが先頭となるようにソートされて保存されうる。取得から一定時間が経過したデータは破棄されうる。

【0071】

環境認識部Ｆ２は、情報取得部Ｆ１が取得した自車位置情報や周辺物体情報、及び地図データに基づいて、自車両の走行環境を認識する。例えば環境認識部Ｆ２は、カメラ１１１とミリ波レーダ１１２など、複数の周辺監視センサ１１の検出結果を、所定の重みで統合するセンサフュージョン処理により、自車両の走行環境を認識する。

【0072】

走行環境には、車両周辺に存在する物体ごとの位置及び種別に加えて、移動体である場合にはその移動速度や移動方向などが含まれる。また走行環境には、走行路の曲率、車線数、自車レーン番号、天候、路面状態、及び渋滞区間に該当するか否かなどが含まれる。自車レーン番号は、左又は右の道路端から何番目のレーンを走行しているかを示す。自車レーン番号の特定は、ロケータ１３にて実施されてもよい。天候や路面状態は、カメラ１１１の認識結果と、情報取得部Ｆ１が取得した天候情報とを組み合わせることにより特定可能である。道路構造に関してはカメラ１１１の認識結果の他、静的地図データを用いて特定されても良い。環境認識部Ｆ２は、道路構造や、天候、路面状態など、ＯＤＤに関連する車外環境情報を取得する。

【0073】

また、環境認識部Ｆ２は、自車両の走行経路上に存在する渋滞を検知する構成として、渋滞認識部Ｆ２１を備える。例えば渋滞認識部Ｆ２１は、交通情報センタ等から受信した情報をもとに渋滞区間及びその長さ（つまり渋滞長）を認識する。なお、交通情報センタ等からの配信された渋滞情報は実際の状況と異なることがありうる。渋滞認識部Ｆ２１は、受信した渋滞情報を、周辺監視センサ１１の検出結果及び自車両の挙動の少なくとも一方を用いて検証した上で、最終的に渋滞の有無を判定してもよい。すなわち、渋滞認識部Ｆ２１は、周辺監視センサ１１の検出結果及び自車両の挙動の少なくとも一方を用いて外部装置から受信した渋滞情報を補正してもよい。

【0074】

渋滞認識部Ｆ２１は、車速情報や、停車及び発進の実行頻度、周辺監視センサ１１の検出結果を用いて自車両の周囲が渋滞状態に該当するか否かを判断してもよい。具体的に、自車両の車速が渋滞判定値以下である状態が所定時間（例えば５分）以上継続した場合に周囲は渋滞状態であると判定する。渋滞認識部Ｆ２１は、先行車両がハザードランプを点灯させたことに基づいて渋滞状態であることの確からしさを高めても良い。渋滞状態であるか否かの判断材料としては、先行車両の挙動を採用可能である。また、渋滞認識部Ｆ２１は、複数の前方車両から車車間通信で取得する車両情報を元に渋滞状態であるか否かを判定してもよい。渋滞認識部Ｆ２１が渋滞情報取得部に相当する。

【0075】

乗員状態取得部Ｆ３は、情報取得部Ｆ１が取得している情報に基づいて、ドライバが起きているか寝ているかといった、乗員の状態を取得する構成である。乗員状態取得部Ｆ３は、ドライバの睡眠深度を判定するサブ機能として睡眠深度判定部Ｆ３１を備える。睡眠深度は、眠りの深さを表すパラメータである。本実施形態では一例として、睡眠深度をレベル０～２の３段階に区分して判定する場合を例に挙げて説明を行う。睡眠深度は、値が大きいほど眠りが深いことを示す。睡眠深度がレベル０の状態はドライバが起きている、つまり眠っていない状態に相当する。レベル１は、眠りが浅い状態、いわゆるレム（ＲＥＭ：Rapid Eye Movement）に相当する。レベル２は、眠りが深い状態、いわゆるノンレム睡眠に相当する。なお、ノンレム睡眠はさらにステージ１～４の４段階に細分化されても良い。睡眠深度判定部Ｆ３１は、睡眠深度を覚醒状態（レベル０）、レム睡眠状態（レベル１）、４段階のノンレム睡眠（レベル２～５）の合計６段階で評価してもよい。睡眠深度判定部Ｆ３１は、ドライバが眠っているか否かを判定する機能を備える。また、睡眠深度など、睡眠深度判定部Ｆ３１の判定結果や乗員状態センサ１６の出力が睡眠状態情報に相当する。

【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】

また、プロセッサ３１は、エネルギー不足以外にも、ドライバ睡眠中かつ渋滞中に天候が変化した場合、例えばゲリラ豪雨に遭遇した場合には、渋滞長等によらずに目立つ態様での渋滞通知を実施してもよい。もちろん、プロセッサ３１は、センタから配信される天気情報に基づき、実際に天候が変化したことを検出する前、例えば所定時間以内に所定レベル以上の降雨が遭遇することを検出したタイミングで、目立つ態様での渋滞通知を実施しても良い。

【0151】

また、渋滞中は移動速度が低下するため、出発時／自動運転開始時には遭遇しないはずであった降雨に見舞われることがある。また、降雨量によってはＯＤＤ外となることが起こりうる。プロセッサ３１は、自動運転開始時には予見されていなかった環境要素によってＯＤＤ退出予定時刻に所定値以上早まった場合、或いは、ＯＤＤ退出予定時刻を早めうる環境要素が検出された場合、目立つ態様で現況を通知してもよい。通知内容は、渋滞中であること、及び、自動運転の終了が早まる可能性が有ることを含むことが好ましい。当該構成によれば、実際にＯＤＤを退出する時点においてドライバが起きている可能性が高めることができ、その結果として、運転交代をよりスムーズに実施可能となりうる。なお、ＯＤＤの退出予定時刻とは、ハンドオーバーリクエストを実施し、自動運転を終了する時刻に相当する。ＯＤＤ退出予定時刻を早めうる環境要素は、自動運転を終了させうる環境要素であって、例えば所定量以上の降雨や、降雪、濃霧、路面凍結などを指す。エネルギー残量が所定値以下となったことや、自動運転を終了させうる環境要素の発生が通知対象事象に相当する。

【0152】

＜変形例（１３）＞
自動運転システムＳｙｓは、図１１に示すようにディスプレイ２１等の報知デバイスを統括制御するＨＣＵ２４を備えていても良い。なお、図１１では図１や図２に示す構成の一部の図示を省略している。ＨＣＵ２４はプロセッサ２４１やメモリ２４２を用いて実現されている。

【0153】

また、渋滞の通知制御に係る機能は、ＨＣＵ２４が備えていても良い。すなわち、ＨＣＵ２４は前述の情報取得部Ｆ１、渋滞認識部Ｆ２１、乗員状態取得部Ｆ３、通知処理部Ｆ６１といった渋滞の通知制御にかかる機能部に加えて、運転モード取得部Ｆ７を備える。運転モード取得部Ｆ７は、自動運転ＥＣＵ３０から現在の動作モードを取得する構成である。運転モード取得部Ｆ７は、自動化レベル４又は５相当の自動運転を実行中であるか否かを示す信号を自動運転ＥＣＵ３０から取得する。

【0154】

上記構成においてＨＣＵ２４は、上述した自動運転ＥＣＵ３０と同様に、自動運転が実行されている間は、ドライバが眠っているか否か、及び、渋滞長の少なくとも何れか一方に基づいて、自車両が遭遇している／遭遇予定の渋滞の通知態様を変更する。ＨＣＵ２０４は、ドライバが寝ている間のエネルギー残量の低下やＯＤＤ退出残余時間等に係る通知も制御しうる。ＨＣＵ２４や自動運転ＥＣＵ３０において渋滞情報の通知態様を調整する機能部を含む構成が通知制御装置に相当する。また、これらが実行する方法が通知制御方法に相当する。

【0155】

＜付言＞
本開示に記載の装置、システム、並びにそれらの手法は、コンピュータプログラムにより具体化された一つ乃至は複数の機能を実行するようにプログラムされたプロセッサを構成する専用コンピュータにより、実現されてもよい。また、本開示に記載の装置及びその手法は、専用ハードウェア論理回路を用いて実現されてもよい。さらに、本開示に記載の装置及びその手法は、コンピュータプログラムを実行するプロセッサと一つ以上のハードウェア論理回路との組み合わせにより構成された一つ以上の専用コンピュータにより、実現されてもよい。例えばプロセッサ３１が備える機能の一部又は全部はハードウェアとして実現されても良い。或る機能をハードウェアとして実現する態様には、１つ又は複数のＩＣなどを用いて実現する態様が含まれる。プロセッサ（演算コア）としては、ＣＰＵや、ＭＰＵ、ＧＰＵ、ＤＦＰ（Data Flow Processor）などを採用可能である。また、プロセッサ３１が備える機能の一部又は全部は、複数種類の演算処理装置を組み合わせて実現されていてもよい。プロセッサ３１が備える機能の一部又は全部は、システムオンチップ（ＳｏＣ：System-on-Chip）や、ＦＰＧＡ、ＡＳＩＣなどを用いて実現されていても良い。ＦＰＧＡはField-Programmable Gate Arrayの略である。ＡＳＩＣはApplication Specific Integrated Circuitの略である。プロセッサ２４１についても同様である。

【0156】

また、コンピュータプログラムは、コンピュータにより実行されるインストラクションとして、コンピュータ読み取り可能な非遷移有形記録媒体（non-transitory tangible storage medium）に記憶されていてもよい。プログラムの保存媒体としては、ＨＤＤ（Hard-disk Drive）やＳＳＤ（Solid State Drive）、フラッシュメモリ等を採用可能である。

【0157】

上述したプロセッサ３１の他、当該プロセッサ３１を構成要素とするシステムなど、多様な形態も本開示の範囲に含まれる。例えば、コンピュータを自動運転ＥＣＵ３０／ＨＣＵ２４として機能させるためのプログラムや、当該プログラムを記録した半導体メモリ等の非遷移的実態的記録媒体等の形態も本開示の範囲に含まれる。

【符号の説明】

【0158】

Ｓｙｓ 自動運転システム、１１ 周辺監視センサ、１２ 車両状態センサ、１５ 無線通信機、１６ 乗員状態センサ、２０ 車載ＨＭＩ、２１ ディスプレイ（報知デバイス）、２２ スピーカ（報知デバイス）、２３ 入力装置、３０ 自動運転ＥＣＵ、３１ プロセッサ、２４１ プロセッサ、Ｆ１ 情報取得部、Ｆ２ 環境認識部、Ｆ２１ 渋滞認識部（渋滞情報取得部）、Ｆ３ 乗員状態取得部、Ｆ４ モード制御部、Ｆ５ 計画部、Ｆ６ 制御実行部、Ｆ６１ 通知処理部、Ｆ７ 運転モード取得部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】