WO2017187759A1

WO2017187759A1 - 支援システム、携帯端末、及び車載装置

Info

Publication number: WO2017187759A1
Application number: PCT/JP2017/007589
Authority: WO
Inventors: 大貴五藤; 哲洋林
Original assignee: 株式会社デンソー
Priority date: 2016-04-27
Filing date: 2017-02-28
Publication date: 2017-11-02

Abstract

支援システムは、自動運転を行うとともに、前記自動運転時においてドライバ動作が必要となることがある車両で用いられる車載装置（１１，１１ａ，１１ｂ，２０，２０ａ）と、前記車両のドライバに携行されるとともに前記車載装置と接続して通信を行う携帯端末（２，２ａ，２ｂ）とを含む。前記車載装置及び前記携帯端末のいずれかは、前記携帯端末が操作中か否かを判定する操作判定部（２０２，１１６）を備える。前記携帯端末は、前記自動運転時において前記ドライバ動作が必要となった場合であって、且つ、前記操作判定部で前記携帯端末が操作中と判定した場合に、前記自動運転時において必要となった前記ドライバ動作の実行を支援する旨の支援表示を行う表示部（２１０）を備える。

Description

支援システム、携帯端末、及び車載装置

関連出願の相互参照

　本出願は、２０１６年４月２７日に出願された日本特許出願番号２０１６－８９７５６号および２０１６年１２月１日に出願された日本特許出願番号２０１６―２３４３７２号に基づくもので、ここにその記載内容を援用する。

　本開示は、自動運転時において必要となったドライバによる操作、回答、及び確認の少なくともいずれかであるドライバ動作の実行を支援する支援システム、携帯端末、及び車載装置に関するものである。

　従来、車両の加速、制動、及び操舵を自動で制御する自動運転とドライバが手動で運転操作を行う手動運転とを切り替える技術が知られている。また、自動運転から手動運転への切り替えをドライバに通知する技術が知られている。例えば、特許文献１には、自動運転から手動運転に切り替える場合に、ナビゲーション装置の液晶ディスプレイ等から通知を行う技術が開示されている。

特開２０１６－５０９００号公報

　将来的には、自動運転時において、ドライバが持ち込んだ多機能携帯電話機、ノートＰＣ、及びタブレット端末といった携帯端末の操作が許可されることが想定される。自動運転時においてドライバが持ち込んだ携帯端末の操作が許可された場合、特許文献１に開示の技術では、ドライバが携帯端末の操作に夢中になることでナビゲーション装置からの通知に気づきにくくなるおそれがある。よって、自動運転から手動運転への切り替えの通知に気づくのが遅れ、自動運転から手動運転への運転交代がスムーズに行われにくくなる問題点が生じる。

　本開示は、ドライバが車両に持ち込んだ携帯端末の操作を行っている場合であっても、自動運転時において必要となったドライバによる操作、回答、及び確認の少なくともいずれかであるドライバ動作の実行をよりスムーズに行わせることを可能にする運転交代支援システム、携帯端末、及び車載装置を提供することを目的とする。

　本開示の第一の態様において、支援システムは、加速、制動、及び操舵を自動で制御する自動運転を行うとともに、前記自動運転時においてドライバによる操作、回答、及び確認の少なくともいずれかであるドライバ動作が必要となることがある車両で用いられる車載装置と、前記車両のドライバに携行されるとともに前記車載装置と接続して通信を行う携帯端末とを含む。前記車載装置及び前記携帯端末のいずれかは、前記携帯端末が操作中か否かを判定する操作判定部を備える。前記携帯端末は、前記自動運転時において前記ドライバ動作が必要となった場合であって、且つ、前記操作判定部で前記携帯端末が操作中と判定した場合に、前記自動運転時において必要となった前記ドライバ動作の実行を支援する旨の支援表示を行う表示部を備える。

　本開示の第二の態様において、車両のドライバに携行される携帯端末は、加速、制動、及び操舵を自動で制御する自動運転を行うとともに、前記自動運転時においてドライバによる操作、回答、及び確認の少なくともいずれかであるドライバ動作が必要となることがある前記車両で用いられ、前記自動運転時において前記ドライバ動作が必要となった場合に前記ドライバ動作が必要となったことを示す要求通知を送信させる車載装置と接続して通信を行う通信部と、前記要求通知を前記通信部で受信した場合に、自端末が操作中か否かを判定する操作判定部と、前記操作判定部で前記携帯端末が操作中と判定した場合に、前記自動運転時において必要となった前記ドライバ動作の実行を支援する旨の支援表示を行う表示部とを備える。

　本開示の第三の態様において、加速、制動、及び操舵を自動で制御する自動運転を行うとともに、前記自動運転時においてドライバによる操作、回答、及び確認の少なくともいずれかであるドライバ動作が必要となることがある車両で用いられ、前記車両のドライバに携行される携帯端末と接続して通信を行う車載装置は、前記自動運転時において前記ドライバ動作が必要となった場合であって、且つ、前記携帯端末と接続可能である場合に、前記携帯端末が操作中か否かを判定できる判定用情報を前記携帯端末から取得する判定情報取得部と、前記判定情報取得部で取得した前記判定用情報をもとに前記携帯端末が操作中か否かを判定する操作判定部と、前記操作判定部で前記携帯端末が操作中と判定した場合に、前記自動運転時において必要となった前記ドライバ動作の実行を支援する旨の支援表示を行わせる指示を前記携帯端末に送信させる指示処理部とを備える。

　上記の支援システム、携帯端末、車載装置によれば、自動運転時においてドライバによる操作、回答、及び確認の少なくともいずれかであるドライバ動作が必要となった場合であって、且つ、携帯端末が操作中と判定した場合に、自動運転時において必要となったドライバ動作の実行を支援する旨の支援表示を携帯端末で行うことになる。携帯端末は車両のドライバに携行されるものであるので、自動運転時において車両に持ち込まれることになる。また、携帯端末が操作中と判定した場合に支援表示を携帯端末で行うので、自動運転時にドライバが携帯端末の操作に夢中になっている場合であっても、支援表示に気付くことができる。よって、ドライバが車両に持ち込んだ携帯端末の操作を行っている場合であっても、自動運転時において必要となったドライバによる操作、回答、及び確認の少なくともいずれかであるドライバ動作の実行をよりスムーズに行わせることが可能になる。

　本開示についての上記目的およびその他の目的、特徴や利点は、添付の図面を参照しながら下記の詳細な記述により、より明確になる。その図面は、
図１は、支援システムの概略的な構成の一例を示す図であり、図２は、車両側ユニットの概略的な構成の一例を示す図であり、図３は、ＨＣＵの概略的な構成の一例を示す図であり、図４は、実施形態１におけるＨＣＵでの操作要否関連処理の流れの一例を示すフローチャートであり、図５は、携帯端末の概略的な構成の一例を示す図であり、図６は、実施形態１における支援表示の一例を示す図であり、図７は、実施形態１における支援表示の一例を示す図であり、図８は、携帯端末２での要求対応処理の流れの一例を示すフローチャートであり、図９は、変形例１における支援表示の一例を示す図であり、図１０は、変形例１における支援表示の一例を示す図であり、図１１は、変形例１におけるＨＣＵ１１での操作要否関連処理の流れの一例を示すフローチャートであり、図１２は、変形例２における支援表示の一例を示す図であり、図１３は、変形例２における支援表示の一例を示す図であり、図１４は、変形例４における支援表示の一例を示す図であり、図１５は、変形例４における支援表示の一例を示す図であり、図１６は、変形例５における支援表示の一例を示す図であり、図１７は、変形例５における支援表示の一例を示す図であり、図１８は、複数種類の支援情報の表示タイミングが重なった場合の表示態様の一例を説明するための図であり、図１９は、支援システムの概略的な構成の一例を示す図であり、図２０は、車両側ユニットの概略的な構成の一例を示す図であり、図２１は、ＨＣＵの概略的な構成の一例を示す図であり、図２２は、携帯端末の概略的な構成の一例を示す図であり、図２３は、携帯端末の概略的な構成の一例を示す図であり、図２４は、ＨＣＵの概略的な構成の一例を示す図である。

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

　また、以下に示す実施形態及び変形例は、左側通行が法制化されている地域に対応した実施形態及び変形例であり、右側通行が法制化されている地域では、以下の実施形態と左右が逆になる。

　（実施形態１）
　＜支援システム３の概略構成＞
　以下、本開示の実施形態１の一例について図面を用いて説明する。図１に示すように、支援システム３は、車両側ユニット１及び携帯端末２を含んでいる。車両側ユニット１は、加速、制動、及び操舵を自動で制御する自動運転を行う車両ＨＶに搭載され、携帯端末２と接続して通信を行う。車両ＨＶは、自動車であって、自動運転とドライバが手動で運転操作を行う手動運転とを切り替え可能であるものとする。

　携帯端末２は、車両ＨＶのドライバに携行されるものであって、ドライバが車両ＨＶに乗車する際に車両ＨＶに持ち込まれるものである。携帯端末２としては、ドライバが携行可能であって表示機能を端末であればよく、例えば多機能携帯電話機、タブレット端末、ノートＰＣ、電子書籍端末、及びスマートウォッチ等を用いることができる。実施形態１では、携帯端末２としてスマートフォンといった多機能携帯電話機を用いる場合を例に挙げて説明を行う。

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

　通信機２０は、近距離無線通信規格に沿って携帯端末２との間で直接的に通信（以下、近距離無線通信）を行う。近距離無線通信の範囲は、例えば半径１ｍ未満程度等とすればよい。通信機２０は、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＺｉｇＢｅｅ（登録商標）等の近距離無線通信規格に沿って信号を送受信する構成とすればよいが、以下ではＢｌｕｅｔｏｏｔｈの規格に沿って信号を送受信する場合を例に挙げて説明を行う。なお、消費電力低減の観点からは、ＢｌｕｅｔｏｏｔｈＬｏｗＥｎｅｒｇｙの規格に沿って信号を送受信する構成とすることがより好ましい。

　実施形態１では、車両ＨＶのドライバが携行する携帯端末２と通信機２０とのペアリングが実行済みであるものとして以降の説明を行う。通信機２０は、携帯端末２と接続した場合には、この携帯端末２から取得した情報を車内ＬＡＮへ出力したり、車内ＬＡＮを介してＨＣＵ１１から送信されてきた情報をこの携帯端末２へ送信したりする。

　ＡＤＡＳロケータ３０は、ＧＮＳＳ（Global Navigation Satellite System）受信機３１、慣性センサ３２、地図データを格納した地図データベース（以下、ＤＢ）３３を備えている。ＧＮＳＳ受信機３１は、複数の人工衛星からの測位信号を受信する。慣性センサ３２は、例えば３軸ジャイロセンサ及び３軸加速度センサを備える。地図ＤＢ３３は、不揮発性メモリであって、リンクデータ、ノードデータ、道路形状、構造物等の地図データを格納している。

　ＡＤＡＳロケータ３０は、ＧＮＳＳ受信機３１で受信する測位信号と、慣性センサ３２での計測結果とを組み合わせることにより、ＡＤＡＳロケータ３０を搭載した車両ＨＶの車両位置を逐次測位する。なお、車両位置の測位には、車両ＨＶに搭載された車輪速センサから逐次出力されるパルス信号から求めた走行距離も用いる構成としてもよい。そして、測位した車両位置を車内ＬＡＮへ出力する。また、ＡＤＡＳロケータ３０は、地図ＤＢ３３から地図データを読み出し、車内ＬＡＮへ出力することも行う。なお、地図データは、自車に搭載された例えばＤＣＭといった車載通信モジュールを用いて車両ＨＶの外部から取得する構成としてもよい。

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

　周辺監視センサ５０は、歩行者、人間以外の動物、自転車、オートバイ、及び他車等の移動物体、さらに路上の落下物、ガードレール、縁石、及び樹木等の静止物体といった障害物を検出する。他にも、走行区画線、停止線等の路面標示を検出する。周辺監視センサ５０は、例えば、車両ＨＶ周囲の所定範囲を撮像する周辺監視カメラ、車両ＨＶ周囲の所定範囲に探査波を送信するミリ波レーダ、ソナー、ＬＩＤＡＲ（Light Detection and Ranging/Laser Imaging Detect ion and Ranging）等のセンサである。

　周辺監視カメラとしてはステレオカメラを用いる構成であっても、単眼カメラを用いる構成であってもよい。周辺監視カメラは、逐次撮像する撮像画像をセンシング情報として自動運転ＥＣＵ６０へ逐次出力する。ソナー、ミリ波レーダ、ＬＩＤＡＲ等の探査波を送信するセンサは、障害物によって反射された反射波を受信した場合に得られる受信信号に基づく走査結果をセンシング情報として自動運転ＥＣＵ６０へ逐次出力する。なお、車両ＨＶ前方のセンシングを周辺監視カメラとミリ波レーダとを併用して行う等、複数種類の周辺監視センサ５０が重複したセンシング範囲を有する構成としてもよい。

　自動運転ＥＣＵ６０は、ＡＤＡＳロケータ３０から取得した自車の車両位置及び地図データ、周辺監視センサ５０から取得したセンシング情報等から、自車の走行環境を認識する。自動運転ＥＣＵ６０は、認識した走行環境をもとに、自動運転によって自車を走行させるための走行計画を生成する。例えば中長期の走行計画として、自車を目的地へ向かわせるための推奨経路を生成する。また、推奨経路に従った走行を行うための短期の走行計画を生成する。具体例としては、車線変更のための操舵、速度調整のための加減速、及び障害物回避のための操舵及び制動等の実行を決定する。

　そして、自動運転ＥＣＵ６０は、生成した走行計画に従い、自車の加速、制動、及び／又は操舵を車両制御ＥＣＵ４０に自動で行わせることで、ドライバによる運転操作の代行を行う。また、自動運転ＥＣＵ６０は、自動運転の実施不実施を切り替えられるものとする。自動運転の不実施とは、自車のブレーキ、ステアリング、スロットル、原動力といった主操縦系統について自動化を行わずにドライバが全て操作することを示す。つまり、手動運転である。自動運転ＥＣＵ６０での自動運転の実施不実施の切り替えは、自動運転区間の走行の終了、認識される走行環境若しくは周辺監視センサ５０でのセンシングの不具合等に応じて、自律的に行われる構成とすればよい。他にも、後述する操作デバイス１２へのドライバによる入力操作に従って行われる構成としてもよい。

　ＨＭＩシステム１０は、図２に示すように、ＨＣＵ（Human Machine Interface Control Unit）１１、操作デバイス１２、ウィンカースイッチ１３、表示装置１４、及び音声出力装置１５を備えており、車両ＨＶのドライバからの入力操作を受け付けたり、車両ＨＶのドライバに向けて情報を提示したりする。

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

　ウィンカースイッチ１３は、方向指示器のランプ点灯操作を行うための操作部材であるウィンカーレバーの操作を検出するためのスイッチであって、ウィンカーレバーの操作に応じた右左折時のウィンカー信号を出力する。

　表示装置１４は、テキスト及び／又は画像の表示によって情報提示を行う。表示装置１４としては、例えばコンビネーションメータ、ＣＩＤ（Center Information Display）、ＨＵＤ（Head-Up Display）等がある。音声出力装置１５は、音声の出力によって情報提示を行う。音声出力装置１５としては、例えばオーディオスピーカ等がある。

　ＨＣＵ１１は、ＣＰＵ、揮発性メモリ、不揮発性メモリ、Ｉ／Ｏ、これらを接続するバスを備え、不揮発性メモリに記憶された制御プログラムを実行することで各種の処理を実行する。例えばＨＣＵ１１は、表示装置１４及び／又は音声出力装置１５に情報提示を行わせる。なお、ＨＣＵ１１が実行する機能の一部または全部を、一つあるいは複数のＩＣ等によりハードウェア的に構成してもよい。ＨＣＵ１１の詳細については以下で述べる。

　＜ＨＣＵ１１の概略構成＞
　ここで、図３を用いて、ＨＣＵ１１の概略構成を説明する。図３に示すように、ＨＣＵ１１は、接続判定部１１１、要否判定部１１２、送信処理部１１３、受信処理部１１４、及び提示制御部１１５を備えている。

　接続判定部１１１は、通信機２０の状態をモニタし、携帯端末２と接続可能か否かを判定する。要否判定部１１２は、自動運転ＥＣＵ６０をモニタし、自動運転時においてドライバによる操作、回答、及び確認の少なくともいずれかであるドライバ動作が必要となったか否かを判定する。本実施形態では、自動運転ＥＣＵ６０で自動運転から手動運転への切り替えを行う場合であって、ドライバによる運転操作が必要となった場合に、ドライバ動作が必要となったと判定する場合を例に挙げて以降の説明を行う。また、要否判定部１１２は、必要となったと判定した場合には、ドライバ動作が必要となったことを示す要求通知を送信処理部１１３に出力する。本実施形態の例では、ドライバによる運転操作が必要となったことを示す要求通知を送信処理部１１３に出力する。なお、要求通知には、必要となったドライバ動作の内容も含む構成とすればよい。ここでのドライバ動作は、手動運転への切り替えで必要となるドライバによる運転操作である。

　送信処理部１１３は、通信機２０に情報を出力して通信機２０から携帯端末２へ情報を送信させる。送信処理部１１３は、要求通知を要否判定部１１２から取得した場合に、通信機２０に要求通知を出力し、通信機２０から携帯端末２へ要求通知を送信させる。この送信処理部１１３が通知処理部に相当する。

　通信機２０は、送信処理部１１３から要求通知を取得した場合に、携帯端末２と接続中であった場合には携帯端末２に要求通知を送信する。一方、携帯端末２と接続中でなかった場合は、接続を試み、接続できた場合に要求通知を携帯端末２に送信し、接続が失敗した場合には要求通知を携帯端末２に送信しない。携帯端末２は、通信機２０からこの要求通知を受信した場合に、携帯端末２を操作中か否かの判定を行い、携帯端末２を操作中か否かの判定結果（以下、携帯操作情報）を通信機２０に送信するものとする。

　なお、通信機２０は、携帯端末２以外の通信端末と接続可能であった場合でも、携帯端末２を特定して接続を行い、要求通知を送信する構成とすればよい。例えば、携帯端末２以外の通信端末と接続中であった場合でも、携帯端末２と接続可能であれば携帯端末２以外の通信端末との接続を中止して携帯端末２と接続し、要求通知を送信する構成とすればよい。この場合、ドライバの携帯端末２のＩＤといった識別情報を通信機２０に登録してしまうことで、登録した携帯端末２のみを要求通知を送信する対象とすればよい。この通信機２０及びＨＣＵ１１を備える構成が車載装置に相当する。他の例として、通信機２０は、携帯端末２を特定せずに、携帯端末２を含む接続可能な通信端末全てに要求通知を送信する構成としてもよい。この場合には、ＨＣＵ１１が車載装置に相当する。

　受信処理部１１４は、通信機２０で携帯端末２から送信される携帯操作情報を受信した場合に、この携帯操作情報を取得して、提示制御部１１５に出力する。提示制御部１１５は、要否判定部１１２でドライバ動作が必要となったと判定した場合に、条件に応じて、自動運転時において必要となったドライバ動作の実行を支援する情報提示（以下、支援提示）を行わせる。

　一例としては、接続判定部１１１で携帯端末２と接続可能でないと判定した場合に、表示装置１４及び／又は音声出力装置１５で支援提示を行わせる。また、接続判定部１１１で携帯端末２と接続可能であると判定した場合であって、且つ、受信処理部１１４で取得した携帯操作情報が携帯端末２を操作中でないことを示していた場合にも、表示装置１４及び／又は音声出力装置１５で支援提示を行わせる。一方、接続判定部１１１で携帯端末２と接続可能であると判定した場合であっても、受信処理部１１４で取得した携帯操作情報が携帯端末２を操作中であることを示していた場合には、表示装置１４及び／又は音声出力装置１５で支援提示を行わせない。支援提示の一例としては、自動運転から手動運転への運転交代を促す表示及び／又は音声出力を行わせる構成とすればよい。

　＜ＨＣＵ１１での操作要否関連処理について＞
　ここで、図４のフローチャートを用いて、ＨＣＵ１１での自動運転時においてドライバによる操作が必要となったか否かに応じた処理（以下、操作要否関連処理）の流れの一例について説明を行う。図４のフローチャートは、車両ＨＶの自動運転が開始された場合に開始する構成とすればよい。

　まず、ステップＳ１では、要否判定部１１２が、ドライバ動作が必要となったと判定した場合（Ｓ１でＹＥＳ）に、ステップＳ２に移る。一方、ドライバ動作が必要でないと判定した場合（Ｓ１でＮＯ）には、ステップＳ６に移る。ステップＳ２では、接続判定部１１１が携帯端末２と接続可能であると判定した場合（Ｓ２でＹＥＳ）に、ステップＳ３に移る。一方、携帯端末２と接続可能でないと判定した場合（Ｓ２でＮＯ）には、ステップＳ５に移る。携帯端末２と接続可能でない場合には、通信機２０から携帯端末２へ要求通知を送信できないため、要求通知は送信されないことになる。

　ステップＳ３では、送信処理部１１３が、要否判定部１１２から取得した要求通知を通信機２０に出力し、通信機２０から携帯端末２へ要求通知を送信させる。ステップＳ４では、通信機２０を介して携帯端末２から受信処理部１１４が取得した携帯操作情報が、携帯端末２を操作中であることを示していた場合（Ｓ４でＹＥＳ）に、ステップＳ６に移る。一方、携帯端末２を操作中でないことを示していた場合（Ｓ４でＮＯ）には、ステップＳ５に移る。

　Ｓ２で携帯端末２と接続可能でない場合、若しくはＳ４で携帯端末２を操作中でないことを示していた場合におけるステップＳ５では、提示制御部１１５が支援提示を表示装置１４及び／又は音声出力装置１５で行わせる。この提示制御部１１５が音声出力処理部に相当する。

　ステップＳ６では、操作要否関連処理の終了タイミングであった場合（Ｓ６でＹＥＳ）は、操作要否関連処理を終了する。一方、操作要否関連処理の終了タイミングでなかった場合（Ｓ６でＮＯ）には、Ｓ１に戻って処理を繰り返す。操作要否関連処理の終了タイミングの一例としては、車両ＨＶが自動運転から手動運転に切り替わったこと、車両ＨＶのイグニッション電源がオフになったこと等がある。

　＜携帯端末２の概略構成＞
　続いて、図５を用いて携帯端末２の概略構成を説明する。図５に示すように、携帯端末２は、主制御部２００、表示部２１０、操作入力部２２０、及び通信部２３０を備えている。表示部２１０は、主制御部２００の指示に従ってテキスト及び／又は画像の表示を行う。操作入力部２２０は、ユーザからの操作入力を受け付ける。操作入力部２２０は、メカニカルなスイッチであってもよいし、表示部２１０と一体となったタッチパネルであってもよい。通信部２３０は、車両側ユニット１の通信機２０と通信を行う。通信部２３０は、通信機２０から要求通知を受信した場合に、受信した要求通知を主制御部２００に出力する。また、通信部２３０は、主制御部２００から情報が出力された場合に、この情報を通信機２０へ送信する。

　主制御部２００は、ＣＰＵ、揮発性メモリ、不揮発性メモリ、Ｉ／Ｏ、これらを接続するバスを備え、不揮発性メモリに記憶された制御プログラムを実行することで各種の処理を実行する。主制御部２００は、機能ブロックとして表示制御部２０１及び操作判定部２０２を備える。なお、主制御部２００が実行する機能の一部または全部を、一つあるいは複数のＩＣ等によりハードウェア的に構成してもよい。

　表示制御部２０１は、携帯端末２で実行するアプリケーションソフトウェア（以下、アプリケーション）に応じた表示を表示部２１０に行わせる。また、表示制御部２０１は、携帯端末２の電源がオンになった状態において、操作入力部２２０で一定時間以上操作を受け付けなかった場合に、表示部２１０での表示を一旦中断させて消費電力を抑えるスリープモードに移行する。

　操作判定部２０２は、通信部２３０から出力される要求通知を取得した場合、つまり、通信部２３０で要求通知を受信した場合に、自端末が操作中か否かを判定する。一例としては、表示制御部２０１がスリープモードに移行していなかった場合に自端末が操作中と判定し、表示制御部２０１がスリープモードに移行していた場合には自端末が操作中でないと判定すればよい。他にも、操作入力部２２０で操作入力を受け付けなくなってから一定時間以上経過した場合に自端末が操作中でないと判定する一方、操作入力部２２０で操作入力を受け付けなくなってから一定時間未満は、自端末が操作中であると判定する等の構成としてもよい。

　操作判定部２０２は、自端末が操作中であるか否かを判定した場合に、自端末を操作中か否かの判定結果（つまり、前述の携帯操作情報）を通信部２３０から通信機２０へ送信させる。

　また、操作判定部２０２で携帯端末２が操作中であると判定した場合、表示制御部２０１が、自動運転時において必要となったドライバ動作の実行を支援する情報の表示（以下、支援表示）を表示部２１０に行わせる。表示制御部２０１は、要求通知に含まれるドライバ動作の内容に応じた支援表示を表示部２１０に行わせればよい。本実施形態では、手動運転への切り替えで必要となるドライバによる運転操作を要求する旨の支援表示を行わせることになる。一方、操作判定部２０２で携帯端末２が操作中でないと判定した場合、表示制御部２０１は支援表示を表示部２１０に行わせない。

　支援表示の種類としては、例えば車両制御についてドライバへの操作の要求を行うものである制御関係要求，車両制御についてドライバへの提案を行うものである制御関係提案，ドライバへ車両制御に関わらない提案を行うものである非制御関係提案，及びドライバへ情報の提供を行うものである情報提供がある。

　まず、制御関係要求は、車両制御に関わる要求を行う支援表示である。言い換えると、ドライバに必ず実施してもらわなくてはならない車両制御に関する要求を行う支援表示である。制御関係要求の一例としては、本実施形態，後述の変形例１で述べるような、自動運転から手動運転への切り替えのためにドライバによる運転操作が必要となった場合に行う、手動運転への切り替えで必要となるドライバによる運転操作を要求する旨の支援表示がある。他にも、後述の変形例２，４で述べるような、自車が走行を継続するために不可欠な車線変更若しくは合流のためのドライバによる承認といった回答が必要となった場合に行う、車線変更若しくは合流のためのドライバによる承認を要求する旨の支援表示がある。

　制御関係要求に対してドライバが承認する応答を行う場合、この応答を自車に搭載された操作部材で受け付ける構成とすればよい。例えば、手動運転への切り替えのためのドライバによる運転操作を要求する旨の支援表示に対しては、自動運転を終了する旨の入力操作をこの応答として操作デバイス１２で受け付ける構成とすればよい。車線変更若しくは合流のためのドライバによる承認を要求する旨の支援表示に対しては、車線変更，合流の方向へのレバー操作をこの応答としてウィンカーレバーで受け付ける構成とすればよい。また、許諾を示す旨の入力操作をこの応答としてステアリングスイッチといった操作デバイス１２で受け付ける構成としてもよい。なお、制御関係要求の表示に対しては、ドライバが要求を却下する応答を行うことはできない構成となっていることが好ましい。一例として、ドライバが要求を承認しないまま車線変更，合流のタイミングとなった場合には、承認されるまで自車を一時停止させる構成とすればよい。

　また、制御関係要求の表示を終了するのは、ドライバから要求を承認する応答を受け付けた場合とすればよい。一例としては、ドライバから要求に従う応答を操作デバイス１２若しくはウィンカーレバーで受け付けた場合に、ＨＣＵ１１が信号を携帯端末２に送信することで、制御関係要求の表示を終了させる構成とすればよい。

　続いて、制御関係提案は、車両制御に関わる提案を行う支援表示である。言い換えると、ドライバに必ずしも実施してもらわなくてもよい車両制御に関する提案を行う支援表示である。この制御関係提案が、ドライバに回答を求める問い合わせを支援する旨の支援表示に相当する。制御関係提案の一例としては、後述の変形例２で述べるような、自車が走行を継続するために必須でない車線変更若しくは追い越しのためのドライバによる承認が必要となった場合に行う、車線変更若しくは追い越しを提案する旨の支援表示がある。また、制御関係提案としては、後述の変形例３で述べるような、緊急車両の接近に伴う路肩での停車のためのドライバによる承認が必要となった場合に行う、路肩での停車を提案する旨の支援表示がある。

　制御関係提案の表示に対してドライバが承認する応答を行う場合、この応答を自車に搭載された操作部材で受け付ける構成とすればよい。例えば、車線変更，路肩での停車を提案する旨の支援表示に対しては、車線変更，路肩での停車の方向へのレバー操作を、提案を承認する応答としてウィンカーレバーで受け付ける構成とすればよい。また、許諾を示す旨の入力操作を、提案を承認する応答としてステアリングスイッチといった操作デバイス１２で受け付ける構成としてもよい。

　一方、制御関係提案の表示に対してドライバが却下する応答を行う場合にも、この応答を自車に搭載された操作部材で受け付ける構成とすればよい。例えば、却下を示す旨の入力操作を、提案を却下する応答としてステアリングスイッチといった操作デバイス１２で受け付ける構成とすればよい。なお、制御関係提案の表示が行われてから一定時間以内に提案を承認する応答が行われないことを、提案を却下する応答としてＨＣＵ１１が受け付ける構成としてもよい。

　また、制御関係提案の表示を終了するのは、ドライバから提案を承認する応答を受け付けたり、ドライバから提案を却下する応答を受け付けたりした場合とすればよい。なお、制御関係提案の表示が行われてから一定時間以内に承認する応答が行われないことを、提案を却下する応答として受け付ける構成を採用した場合には、制御関係提案の表示が行われてから一定時間以内に承認する応答が行われない場合に、制御関係提案の表示を終了することになる。他にも、追い越し対象の先行車の車線変更若しくは加速があった場合，緊急車両の経路から外れた場合等の、制御関係提案が無効になった場合に、制御関係提案の表示を終了する構成とすればよい。制御関係提案の表示を終了する場合も、ＨＣＵ１１が信号を携帯端末２に送信することで、制御関係提案の表示を終了させる構成とすればよい。

　なお、制御関係提案の承認，却下の応答の受け付けは、自車に搭載された操作部材で受け付ける構成が好ましいが、自車に搭載された操作部材で受け付ける構成に限らない。例えば、車両ＨＶに音声認識ユニットが搭載されていたり、携帯端末２が音声認識機能を有していたりする場合には、音声による承認，却下の応答を音声認識することで、提案の承認，却下の応答を受け付ける構成としてもよい。

　続いて、非制御関係提案は、車両制御に関わらない提案を行う支援表示である。言い換えると、ドライバに必ずしも実施してもらわなくてもよい、直近の車両制御に関わらない提案を行う支援表示である。この非制御関係提案も、ドライバに回答を求める問い合わせを支援する旨の支援表示に相当する。非制御関係提案の一例としては、後述の変形例５で述べるような、自動運転時に立ち寄り可能な地点への立ち寄りのためのドライバによる承認が必要となった場合に行う、立ち寄り可能な地点への立ち寄りを提案する旨の支援表示がある。他にも、後述の変形例６で述べるような、自動運転の経路変更を行うためのドライバによる承認，選択といった回答が必要となった場合に行う、自動運転の経路変更を提案する旨の支援表示がある。ドライバによる選択が必要になる場合とは、複数候補の提案に対する選択が必要である等の、承認及び却下のみでの応答が困難な非制御関係提案が行われた場合である。

　非制御関係提案の表示に対してドライバが承認，選択，却下する応答を行う場合、この応答を、自車に搭載された操作部材若しくは携帯端末２の操作入力部２２０で受け付ける構成とすればよい。例えば、承認，選択，却下する応答を、自車に搭載された操作部材で受け付ける場合には、表示装置１４と一体となったタッチスイッチといった操作デバイス１２で受け付ける構成とすればよい。

　また、非制御関係提案に対して承認，選択，却下する応答を、携帯端末２の操作入力部２２０で受け付ける場合には、表示部２１０と一体となったタッチパネルで受け付ける構成とすればよい。例えば、タッチパネルの画面上に表示した承認，却下を示す内容のボタンの操作を、非制御関係提案に対して承認，却下する応答として受け付ける構成とすればよい。また、タッチパネルの画面上に表示した複数の選択候補から選択する操作を、非制御関係提案に対して選択する応答として受け付ける構成とすればよい。タッチパネルの画面上の支援表示に、支援表示を閉じるボタンが含まれている場合には、この閉じるボタンの操作を、非制御関係提案を却下する応答として受け付ける構成としてもよい。他にも、タッチパネルの画面上の支援表示に対する、所謂スワイプ操作を、非制御関係提案を却下する応答として受け付ける構成としてもよい。なお、非制御関係提案の表示が行われてから一定時間以内に提案に対して承認，選択する応答が行われないことを、提案を却下する応答として受け付ける構成としてもよい。

　また、非制御関係提案の表示を終了するのは、ドライバから承認，選択，却下する応答を受け付けた場合とすればよい。また、制御関係提案の表示の場合と同様に、非制御関係提案の表示が行われてから一定時間以内に提案に対して承認，選択する応答が行われない場合に、非制御関係提案の表示を終了する構成としてもよい。非制御関係提案を却下する応答を、自車に搭載された操作部材で受け付けた場合には、ＨＣＵ１１が信号を携帯端末２に送信することで、非制御関係提案の表示を終了させる構成とすればよい。

　なお、非制御関係提案の承認，選択，却下の応答の受け付けは、必ずしも自車に搭載された操作部材，携帯端末２の操作入力部２２０で受け付ける構成に限らない。例えば、車両ＨＶに音声認識ユニットが搭載されていたり、携帯端末２が音声認識機能を有していたりする場合には、音声による承認，選択，却下の応答を音声認識することで、承認，選択，却下の応答を受け付ける構成とすればよい。

　続いて、情報提供は、車両ＨＶの運行に関する情報提供を行う支援表示である。言い換えると、ドライバが確認するだけで済む、車両ＨＶの運行に関する情報提供を行う支援表示である。この情報提供が、ドライバに確認を求める問い合わせを支援する旨の支援表示に相当する。情報提供の一例としては、後述の変形例７で述べるような、目的地到着予定時刻が一定時間以上変更された場合に行う、変更された目的地到着予定時刻を通知する旨の支援表示がある。

　情報提供の表示に対してドライバが確認したことを示す応答を行う場合、確認したことを示す応答を、自車に搭載された操作部材若しくは携帯端末２の操作入力部２２０で受け付ける構成とすればよい。例えば、確認したことを示す応答を、自車に搭載された操作部材で受け付ける場合には、表示装置１４と一体となったタッチスイッチといった操作デバイス１２で受け付ける構成とすればよい。

　また、確認したことを示す応答を、携帯端末２の操作入力部２２０で受け付ける場合には、表示部２１０と一体となったタッチパネルで受け付ける構成とすればよい。例えば、タッチパネルの画面上に表示した確認済みを示す内容のボタンの操作を、確認したことを示す応答として受け付ける構成とすればよい。また、タッチパネルの画面上の支援表示に、支援表示を閉じるボタンが含まれている場合には、この閉じるボタンの操作を、確認したことを示す応答として受け付ける構成としてもよい。他にも、タッチパネルの画面上の支援表示に対する、所謂スワイプ操作を、確認したことを示す応答として受け付ける構成としてもよい。

　また、情報提供の表示を終了するのは、ドライバから確認したことを示す応答を受け付けた場合とすればよい。また、情報提供の表示が行われてから一定時間経過した場合に、情報提供の表示を終了する構成としてもよい。確認したことを示す応答を、自車に搭載された操作部材で受け付けた場合には、ＨＣＵ１１が信号を携帯端末２に送信することで、情報提供の表示を終了させる構成とすればよい。

　なお、情報提供の確認したことを示す応答の受け付けは、必ずしも自車に搭載された操作部材，携帯端末２の操作入力部２２０で受け付ける構成に限らない。例えば、車両ＨＶに音声認識ユニットが搭載されていたり、携帯端末２が音声認識機能を有していたりする場合には、音声認識によって受け付ける構成とすればよい。

　また、制御関係要求，制御関係提案といった、直近の車両制御に関わる支援表示へのドライバからの応答については、自車に搭載された操作部材で受け付ける構成としている。一方、非制御関係提案，情報提供といった、直近の車両制御に関わらない支援表示へのドライバからの応答については、携帯端末２でも受け付け可能な構成としている。これによれば、直近の車両制御に関わる支援表示が行われる状況といった、ドライバによる運転操作が必要となりやすい状況では、自車に搭載された操作部材をドライバに操作させることで、運転操作が必要となった場合でもドライバの運転操作への移行を容易にすることが可能になる。一方、直近の車両制御に関わらない支援表示が行われる状況といった、ドライバによる運転操作が必要となりにくい状況では、自車に搭載された操作部材の操作を必須としないことで、携帯端末２の操作を継続したいドライバの煩わしさを軽減することが可能になる。

　なお、制御関係要求，制御関係提案にあたる支援表示を行う場合には、自車の周辺の安全をドライバ自身が確認するよう注意喚起する文言も合わせて表示する構成が好ましい。一例としては、「周辺の安全を確認した上で承認して下さい」といったテキストを表示する構成とすればよい。

　支援表示は、携帯端末２で要求通知を受信する以前から実行していたアプリケーションに応じた表示に例えば重畳して表示させる構成とすればよい。例えばウェブサイトの閲覧中であった場合には、ウェブサイトの表示に重畳して支援表示を行わせる構成とすればよい。支援表示の一例としては、図６のＡ～Ｇに示すようなテキストとアイコンとを組み合わせたバナー表示を行わせる構成とすればよい。他にも、図７に示すようなテキストとアイコンとを組み合わせたポップアップ表示を行わせる構成としてもよい。また、アプリケーションに応じた表示の全面に重畳して支援表示を行わせる構成としてもよい。なお、支援表示は、画面を分割して、携帯端末２で要求通知を受信する以前から実行していたアプリケーションに応じた表示と異なる画面に表示させる構成としてもよい。

　＜携帯端末２での要求対応処理＞
　ここでは、図８のフローチャートを用いて、携帯端末２での要求通知に応じた処理（以下、要求対応処理）の流れの一例について説明を行う。図８のフローチャートは、携帯端末２の電源がオンになった場合に開始する構成とすればよい。

　まず、ステップＳ２１では、通信部２３０が通信機２０から要求通知を受信した場合（Ｓ２１でＹＥＳ）に、ステップＳ２２に移る。一方、要求通知を受信していない場合（Ｓ２１でＮＯ）には、ステップＳ２４に移る。

　ステップＳ２２では、操作判定部２０２が、自端末が操作中か否かを判定する。そして、自端末が操作中と判定した場合（Ｓ２２でＹＥＳ）には、ステップＳ２３に移る。一方、自端末が操作中でないと判定した場合（Ｓ２２ＮＯ）には、ステップＳ２４に移る。ステップＳ２３では、表示制御部２０１が前述の支援表示を表示部２１０に行わせる。

　ステップＳ２４では、要求対応処理の終了タイミングであった場合（Ｓ２４でＹＥＳ）には、要求対応処理を終了する。一方、要求対応処理の終了タイミングでなかった場合（Ｓ２４でＮＯ）には、Ｓ２１に戻って処理を繰り返す。要求対応処理の終了タイミングの一例としては、携帯端末２の電源がオフになったこと等がある。

　＜実施形態１のまとめ＞
　実施形態１の構成によれば、自動運転時においてドライバによる操作、回答、及び確認の少なくともいずれかであるドライバ動作が必要となったことを示す要求通知を車両側ユニット１から携帯端末２が受信した場合であって、且つ、携帯端末２で自端末が操作中と判定した場合に、支援表示を携帯端末２の表示部２１０で行う。携帯端末２は近距離無線通信で車両側ユニット１から要求通知を受信するので、要求通知を受信した場合には、車両ＨＶに持ち込まれていることになる。また、携帯端末２が操作中と判定した場合に支援表示を携帯端末２の表示部２１０で行うので、自動運転時にドライバが携帯端末２の操作に夢中になっている場合であっても、支援表示に気付くことができる。よって、ドライバが車両ＨＶに持ち込んだ携帯端末２の操作を行っている場合であっても、自動運転時において必要となったドライバ動作の実行をよりスムーズに行わせることが可能になる。

　また、実施形態１の構成によれば、要求通知を車両側ユニット１から携帯端末２が受信した場合であって、且つ、携帯端末２で自端末が操作中と判定した場合には、車両側ユニット１の表示装置１４及び／又は音声出力装置１５でその操作の実行を支援する支援提示を行わせない。よって、携帯端末２からの支援表示に重ねて、車両側から支援提示が行われることがない。従って、支援表示に重ねて支援提示が行われることによる煩わしさをドライバが感じにくくなる。

　さらに、実施形態１の構成によれば、自動運転時においてドライバによる動作が必要となった場合であって、携帯端末２と車両側ユニット１とが接続できない場合には、車両側ユニット１の表示装置１４及び／又は音声出力装置１５で支援提示を行う。携帯端末２と車両側ユニット１とが接続できない場合は、携帯端末２の電源をオフにしている、若しくは車両ＨＶへの携帯端末２の持ち込みが行われていない等が考えられる。このように、自動運転時においてドライバが携帯端末２の操作に夢中になり得ない状況では、車両側の表示装置１４及び／又は音声出力装置１５から支援提示を行うことで、自動運転時において必要となったドライバによる操作の実行をスムーズに行わせることが可能になる。

　他にも、実施形態１の構成によれば、自動運転時においてドライバ動作が必要となった場合であって、携帯端末２と車両側ユニット１とが接続できる場合であっても、携帯端末２で自端末が操作中でないと判定した場合には、車両側ユニット１の表示装置１４及び／又は音声出力装置１５で支援提示を行う。よって、携帯端末２が操作中でなく、自動運転時においてドライバが携帯端末２の操作に夢中になっていない状況では、車両側の表示装置１４及び／又は音声出力装置１５から支援提示を行うことで、自動運転時において必要となったドライバ動作の実行をスムーズに行わせることが可能になる。

　（変形例１）
　実施形態１では、自動運転から手動運転への切り替えを行う場合の一例として、手動運転への切り替えまでの時間が比較的短い場合の例を示したが、必ずしもこれに限らない。例えば、自動運転から手動運転への切り替えまでの残り距離及び／又は残り時間が設定値以下となった場合であって、手動運転への切り替えでドライバによる運転操作が必要となる場合に、自動運転時においてドライバ動作が必要となったと要否判定部１１２で判定する構成（以下、変形例１）としてもよい。

　以下、本開示の変形例１の構成について説明する。変形例１の要否判定部１１２は、自動運転ＥＣＵ６０で生成した走行計画をもとに、自動運転区間終了までの残り距離を取得する。そして、この残り距離若しくはこの残り距離から算出される残り時間が設定値以下であった場合に、自動運転時においてドライバ動作が必要となったと判定すればよい。ここでのドライバ動作は、手動運転への切り替えで必要となるドライバによる運転操作である。残り時間については、残り距離と平均車速とから要否判定部１１２で算出する構成とすればよい。ここで言うところの設定値は任意に設定可能な値である。

　また、変形例１の構成では、車両側ユニット１から携帯端末２へ要求通知を送信する際に、自動運転から手動運転への切り替えまでの残り距離及び／又は残り時間も送信し、携帯端末２で支援表示を行う場合に、この残り距離及び／又は残り時間も表示する構成とすればよい。変形例１における支援表示の一例としては、図９に示すようなテキストと画像とを組み合わせたバナー表示を行わせる構成とすればよい。図９のＨが自動運転区間終了までの残り距離を示す場合の例であって、Ｉが自動運転区間終了までの残り時間を示す場合の例である。他にも、図１０に示すようなテキストと画像とを組み合わせたポップアップ表示を行わせる構成としてもよい。図１０は、自動運転区間終了までの残り距離を示す場合の例である。

　ここで、図１１を用いて、変形例１におけるＨＣＵ１１での操作要否関連処理の流れの一例について説明を行う。図１１のフローチャートも、車両ＨＶの自動運転が開始された場合に開始する構成とすればよい。

　まず、ステップＳ４１では、要否判定部１１２が、自動運転ＥＣＵ６０から、自動運転区間終了までの残り距離を取得する。ステップＳ４２では、要否判定部１１２が、Ｓ４１で取得した残り距離と自動運転時における車両ＨＶの平均車速とから、自動運転区間終了までの残り時間を算出する。

　ステップＳ４３では、Ｓ４１で取得した残り距離が設定値以下であった場合（Ｓ４３でＹＥＳ）には、ステップＳ４５に移る。一方、設定値よりも長かった場合（Ｓ４３でＮＯ）には、ステップＳ４４に移る。ステップＳ４４では、Ｓ４２で算出した残り時間が設定値以下であった場合（Ｓ４４でＹＥＳ）には、ステップＳ４５に移る。一方、設定値よりも長かった場合（Ｓ４４でＮＯ）には、ステップＳ４９に移る。なお、Ｓ４３で用いる設定値と、Ｓ４４で用いる設定値とは異なるものとする。

　ステップＳ４５～ステップＳ４９の処理は、前述のＳ２～Ｓ６の処理と同様である。Ｓ４３でＹＥＳであった場合であって、且つ、Ｓ４６で要求通知を送信する場合には、Ｓ４１で取得した残り距離も携帯端末２へ送信する。そして、要求通知と残り距離とを受信した携帯端末２において自端末を操作中と判定した場合には、残り距離を示した支援表示を行う。一方、Ｓ４４でＹＥＳであった場合であって、且つ、Ｓ４６で要求通知を送信する場合には、Ｓ４２で算出した残り時間も携帯端末２へ送信する。そして、要求通知と残り時間とを受信した携帯端末２において自端末を操作中と判定した場合には、残り時間を示した支援表示を行う。

　（変形例２）
　実施形態１及び変形例１では、自動運転ＥＣＵ６０で自動運転から手動運転への切り替えを行う場合に、自動運転時においてドライバ動作が必要となったと要否判定部１１２で判定する構成を示したが、必ずしもこれに限らない。例えば、自動運転時において車線変更及び追い越しを行う際にドライバによる承認が必要な場合には、自動運転時に車線変更若しくは追い越しを行う場合に、自動運転時においてドライバ動作が必要となったと要否判定部１１２で判定する構成（以下、変形例２）としてもよい。

　以下、本開示の変形例２の構成について説明する。変形例２の要否判定部１１２は、自動運転ＥＣＵ６０で生成した走行計画をもとに、車両ＨＶが自動で走行を継続するために不可欠な車線変更が必要となった場合に、自動運転時においてドライバ動作が必要となったと判定する。一例として、右左折のためにそれぞれの専用レーンに移る必要がある場合，自車線前方で工事による車線規制が行われている場合等が、走行継続に不可欠な車線変更が必要となった場合に該当する。

　また、要否判定部１１２は、自動運転ＥＣＵ６０で認識した自車の走行環境等をもとに、車両ＨＶが自動で走行を継続するために必ずしも必要でない車線変更若しくは追い越しを提案する場合に、自動運転時においてドライバ動作が必要となったと判定する。一例として、自車と先行車との車間距離が閾値未満となった走行が一定時間以上継続された場合等が、車両ＨＶが自動で走行を継続するために必ずしも必要でない車線変更若しくは追い越しを提案する場合に該当する。

　要否判定部１１２は、走行継続に不可欠な車線変更を行う状況において、ドライバ動作が必要となったと判定した場合に、走行継続に不可欠な車線変更についてのドライバによる承認が必要となったことを示す要求通知を送信処理部１１３に出力する。一方、要否判定部１１２は、走行継続に不可欠でない車線変更若しくは追い越しを提案する状況において、ドライバ動作が必要となったと判定した場合に、走行継続に不可欠でない車線変更若しくは追い越しについてのドライバによる承認が必要となったことを示す要求通知を送信処理部１１３に出力する。

　そして、携帯端末２の表示制御部２０１では、車両側ユニット１から送信された上述の要求通知に含まれるドライバ動作の内容に応じた支援表示を表示部２１０に行わせる。走行継続に不可欠な車線変更についてのドライバによる承認が必要となったことを示す要求通知に対しては、前述の制御関係要求にあたる支援表示を行うことになる。一方、走行継続に不可欠でない車線変更若しくは追い越しについてのドライバによる承認が必要となったことを示す要求通知に対しては、前述の制御関係提案にあたる支援表示を行うことになる。

　また、ドライバによる承認は、前述したようにウィンカーレバーの操作，操作デバイス１２の操作等によって行う構成とすればよい。変形例２の構成では、車両側ユニット１から携帯端末２へ要求通知を送信する際に、車両ＨＶが行う車線変更若しくは追い越しの方向も送信し、携帯端末２で車両ＨＶが行う車線変更若しくは追い越しの方向に応じた支援表示を行う構成とすればよい。

　変形例２での制御関係提案にあたる支援表示の一例としては、図１２に示すようなテキストとアイコンとを組み合わせたバナー表示を行わせる構成とすればよい。図１２のＪが右方向に車線変更を行うことを提案する場合の支援表示の例であって、Ｋが追い越しを行うことを提案する場合の支援表示の例である。他にも、図１３に示すようなテキストとアイコンとを組み合わせたポップアップ表示を行わせる構成としてもよい。図１３は、右方向に車線変更を行うことを提案する場合の例である。制御関係要求にあたる支援表示を行う場合には、図１２～図１３で示すテキストの内容を、問いかける内容から要求する内容に変更すればよい。

　（変形例３）
　また、緊急車両の接近に伴う路肩での停車のためのドライバによる承認が必要となった場合に、自動運転時においてドライバ動作が必要となったと要否判定部１１２で判定する構成（以下、変形例３）としてもよい。

　以下、本開示の変形例３の構成について説明する。変形例３では、車両側ユニット１は、車両ＨＶの車外と通信を行う通信モジュールを備えているものとする。この通信モジュールは、一例として緊急車両から逐次送信される緊急車両の位置情報を逐次受信するものとする。そして、ＨＣＵ１１は、この通信モジュールで逐次受信した緊急車両の位置情報と、ＡＤＡＳロケータ３０で測位した自車の車両位置とを用いて、公知の方法を用いて自車への緊急車両の接近を検出する。一例としては、自車と緊急車両との位置するリンクが同一であって緊急車両の経路に自車が位置し、自車と緊急車両との距離が例えば数十ｍ等の閾値未満となった場合に、緊急車両の接近を検出する構成とすればよい。

　変形例３の要否判定部１１２は、ＨＣＵ１１で緊急車両の接近を検出した場合であって、自車位置が交差点近辺でない場合に、自動運転時においてドライバ動作が必要となったと判定する。自車位置が交差点近辺か否かについては、ＡＤＡＳロケータ３０で測位した自車の車両位置と交差点を示すノードとの距離が交差点近辺か否かを判別するための閾値以上か否かによって判別すればよい。変形例３の要否判定部１１２は、緊急車両の接近を検出した状況において、ドライバ動作が必要となったと判定した場合に、路肩での停車ついてのドライバによる承認が必要となったことを示す要求通知を送信処理部１１３に出力する。

　そして、携帯端末２の表示制御部２０１では、車両側ユニット１から送信された上述の要求通知に含まれるドライバ動作の内容に応じた支援表示を表示部２１０に行わせる。路肩での停車ついてのドライバによる承認が必要となったことを示す要求通知に対しては、前述の制御関係提案にあたる支援表示を行うことになる。具体例としては、緊急車両が接近していること及び路肩への停車の提案を表す内容の支援表示を行う構成とすればよい。また、ドライバによる承認は、前述したようにウィンカーレバーの操作，操作デバイス１２の操作等によって行う構成とすればよい。ドライバによる却下は、前述したように操作デバイス１２の操作等によって行う構成とすればよい。

　ドライバによる承認が行われた場合には、自動運転ＥＣＵ６０が、自車を路肩に寄せて停車させるものとする。なお、ドライバによる却下が行われた場合にも、自動運転ＥＣＵ６０は、緊急車両の接近を検出した状況においては、自車を路肩に寄せて走行させることが好ましい。

　（変形例４）
　また、自動運転時において本線への合流を行う際にドライバによる承認の操作が必要な場合には、自動運転時に本線への合流を行う場合に、自動運転時においてドライバ動作が必要となったと要否判定部１１２で判定する構成（以下、変形例４）としてもよい。

　以下、本開示の変形例４の構成について説明する。変形例４の要否判定部１１２は、自動運転ＥＣＵ６０で生成した走行計画をもとに、車両ＨＶが自動で本線への合流を行う場合に、自動運転時においてドライバ動作が必要となったと判定すればよい。変形例４の要否判定部１１２は、車両ＨＶが自動で本線への合流を行う状況においてドライバ動作が必要となったと判定した場合に、本線への合流についてのドライバによる承認が必要となったことを示す要求通知を送信処理部１１３に出力する。

　そして、携帯端末２の表示制御部２０１では、車両側ユニット１から送信された上述の要求通知に含まれるドライバ動作の内容に応じた支援表示を表示部２１０に行わせる。本線への合流についてのドライバによる承認が必要となったことを示す要求通知に対しては、前述の制御関係要求にあたる支援表示を行うことになる。

　また、ドライバによる承認は、前述したようにウィンカーレバーの操作，操作デバイス１２の操作等によって行う構成とすればよい。変形例４の構成では、車両側ユニット１から携帯端末２へ要求通知を送信する際に、本線への合流を行うことを示す情報も送信し、携帯端末２で本線へ合流に応じた支援表示を行う構成とすればよい。

　変形例４における支援表示は、図１４に示すようなテキストとアイコンとを組み合わせたバナー表示としてもよいし、図１５に示すようなテキストとアイコンとを組み合わせたポップアップ表示としてもよい。

　（変形例５）
　また、自動運転時において立ち寄り可能な地点までの残り距離及び／又は残り時間が設定値以下となった場合であって、この立ち寄り可能な地点への立ち寄りを提案する場合に、自動運転時においてドライバ動作が必要となったと要否判定部１１２で判定する構成（以下、変形例５）としてもよい。立ち寄り可能な地点の一例としては、サービスエリア（以下、ＳＡ），パーキングエリア（以下、ＰＡ）等がある。以下ではＳＡを例に挙げて説明を行う。

　以下、本開示の変形例５の構成について説明する。変形例４の要否判定部１１２は、自動運転ＥＣＵ６０の走行計画と地図データとをもとに、進路前方の直近のＳＡまでの残り距離を取得する。そして、この残り距離若しくはこの残り距離から算出される残り時間が設定値以下であった場合に、自動運転時においてドライバ動作が必要となったと判定する。残り時間については、残り距離と平均車速とから要否判定部１１２で算出する構成とすればよい。ここで言うところの設定値は任意に設定可能な値である。

　変形例５の要否判定部１１２は、立ち寄り可能な地点までの残り距離及び／又は残り時間が設定値以下となった状況においてドライバ動作が必要となったと判定した場合に、立ち寄り可能な地点への立ち寄りについてのドライバによる承認が必要となったことを示す要求通知を送信処理部１１３に出力する。

　そして、携帯端末２の表示制御部２０１では、車両側ユニット１から送信された上述の要求通知に含まれるドライバ動作の内容に応じた支援表示を表示部２１０に行わせる。立ち寄り可能な地点への立ち寄りついてのドライバによる承認が必要となったことを示す要求通知に対しては、前述の非制御関係提案にあたる支援表示を行うことになる。具体例としては、立ち寄り可能な地点への立ち寄りの提案を表す内容の支援表示を行う構成とすればよい。また、ドライバによる承認，却下は、前述したように操作デバイス１２，携帯端末２の操作等によって行う構成とすればよい。

　変形例５の構成では、車両側ユニット１から携帯端末２へ要求通知を送信する際に、ＳＡまでの残り距離及び／又は残り時間も送信し、携帯端末２で支援表示を行う場合に、この残り距離及び／又は残り時間も表示する構成とすればよい。なお、ＳＡまでの残り距離及び／又は残り時間に加え、自動運転から手動運転への切り替えまでの残り距離及び／又は残り時間も送信し、これらの残り距離及び／又は残り時間を表示する構成としてもよい。

　変形例５におけるＨＣＵ１１での操作要否関連処理の流れの一例については、自動運転区間終了までの距離及び時間の代わりに、ＳＡまでの距離及び時間を用いる点を除けば、図１１で示した変形例１におけるＨＣＵ１１での操作要否関連処理の流れと同様である。

　変形例５における非制御関係提案にあたる支援表示の一例としては、図１６に示すようなテキストと画像とを組み合わせたバナー表示を行わせる構成とすればよい。図１６のＬがＳＡまでの残り距離を示す場合の例であって、自動運転区間終了（図中のＩＣ）までの距離とＳＡまでの距離との両方を示す画像を含んでいる。図１６のＭがＳＡまでの残り時間を示す場合の例であって、自動運転区間終了（図中のＩＣ）までの時間とＳＡまでの時間との両方を示す画像を含んでいる。このようなバナー表示を目にしたドライバは、ＳＡに立ち寄る意思がある場合には、例えば操作デバイス１２等を操作することで立ち寄りを承認する意思をＨＣＵ１１に伝える構成とすればよい。立ち寄りが承認された場合、ＨＣＵ１１では、ＳＡに立ち寄るよう自動運転ＥＣＵ６０に指示を行う構成とすればよい。

　他にも、図１７に示すようなテキストと画像とを組み合わせたポップアップ表示を行わせる構成としてもよい。図１７は、ＳＡまでの残り距離を示す場合の例である。図１７の例では、自動運転区間終了（図中のＩＣ）までの距離とＳＡまでの距離との両方を示す画像、ＳＡの情報を示す画像、及びボタン表示を含んでいる。このボタン表示はタッチスイッチとして機能するものとする。このようなポップアップ表示を目にしたドライバは、ＳＡに立ち寄る意思がある場合には、例えばポップアップ表示中の「立ち寄る」ボタンのボタン表示を操作することで、立ち寄りを承認する意思を携帯端末２に伝える構成とすればよい。また、立ち寄る意思がない場合には、例えばポップアップ表示中の閉じることを示すボタン表示を操作することで、立ち寄りを却下する意思を携帯端末２に伝える構成とすればよい。なお、「立ち寄る」ボタンのボタン表示を支援表示開始から一定時間以上操作しないことで、立ち寄りを却下する意思を携帯端末２に伝える構成とすればよい。

　立ち寄りが承認された場合、携帯端末２では、ＳＡに立ち寄る意思があることを示す情報を、通信機２０を介してＨＣＵ１１に送信する。ＳＡに立ち寄る意思があることを示す情報を取得したＨＣＵ１１では、ＳＡに立ち寄るよう自動運転ＥＣＵ６０に指示を行う構成とすればよい。立ち寄りが却下された場合、携帯端末２では、ＳＡに立ち寄る意思がないことを示す情報を、通信機２０を介してＨＣＵ１１に送信する。ＳＡに立ち寄る意思がないことを示す情報を取得したＨＣＵ１１では、ＳＡに立ち寄らず自動運転を継続するよう自動運転ＥＣＵ６０に指示を行う構成とすればよい。

　（変形例６）
　また、自動運転の経路変更のためのドライバによる承認，選択が必要となった場合に、自動運転時においてドライバ動作が必要となったと要否判定部１１２で判定する構成（以下、変形例６）としてもよい。

　以下、本開示の変形例６の構成について説明する。変形例６では、車両側ユニット１は、自動運転ＥＣＵ６０で生成した推奨経路を、表示装置１４に表示できるものとする。また、自動運転ＥＣＵ６０は、生成した推奨経路が自動運転の経路として設定された後も、推奨経路の候補を新たに生成し直すものとする。一例として、車両側ユニット１は、センタから交通情報，天気情報を取得する通信モジュールを備えており、自動運転ＥＣＵ６０は、通信モジュールで取得した交通情報，天気情報をもとに、渋滞回避，豪雨地域の回避等のために推奨経路の候補を新たに生成し直すものとする。

　変形例６の要否判定部１１２は、設定済みの自動運転の経路とは異なる推奨経路の候補が自動運転ＥＣＵ６０で生成された場合に、自動運転時においてドライバ動作が必要となったと判定する。変形例６の要否判定部１１２は、設定済みの自動運転の経路とは異なる推奨経路の候補が自動運転ＥＣＵ６０で生成された状況においてドライバ動作が必要となったと判定した場合に、生成した推奨経路の候補に自動運転の経路変更を行うためのドライバによる承認，選択が必要となったことを示す要求通知を送信処理部１１３に出力する。推奨経路の候補が１つの場合には、自動運転の経路変更の承認が必要となったことを示す要求通知とすればよく、推奨経路の候補が複数の場合には、自動運転の経路変更の候補選択が必要となったことを示す要求通知とすればよい。

　そして、携帯端末２の表示制御部２０１では、車両側ユニット１から送信された上述の要求通知に含まれるドライバ動作の内容に応じた支援表示を表示部２１０に行わせる。推奨経路の候補の承認，選択が必要となったことを示す要求通知に対しては、前述の非制御関係提案にあたる支援表示を行うことになる。具体例としては、自動運転の経路変更の提案を表す内容の支援表示を行う構成とすればよい。また、ドライバによる承認，選択，却下は、前述したように操作デバイス１２の操作，携帯端末２の操作等によって行う構成とすればよい。

　変形例６の構成では、車両側ユニット１から携帯端末２へ要求通知を送信する際に、推奨経路の候補の情報も送信し、携帯端末２で支援表示を行う場合に、この推奨経路の候補の情報も表示する構成とすればよい。推奨経路の候補が１つの場合には、ドライバがこの１つの候補を承認するか却下する構成とすればよく、推奨経路の候補が複数の場合には、この複数の候補のいずれかを選択するか却下する構成とすればよい。

　承認，選択，却下を操作デバイス１２で受け付ける場合には、自動運転ＥＣＵ６０が、自動運転の経路を、承認，選択された推奨経路に変更する構成とすればよい。一方、承認，選択，却下を携帯端末２で受け付ける場合には、携帯端末２では、承認，選択された推奨経路の情報を、通信機２０を介して自動運転ＥＣＵ６０に送信する。承認，選択された推奨経路の情報を取得した自動運転ＥＣＵ６０では、自動運転の経路を、承認，選択された推奨経路に変更する構成とすればよい。

　（変形例７）
　また、情報提供に対するドライバの確認が必要となった場合に、自動運転時においてドライバ動作が必要となったと要否判定部１１２で判定する構成（以下、変形例７）としてもよい。

　以下、本開示の変形例７の構成について説明する。変形例７では、自動運転ＥＣＵ６０は、生成した推奨経路での目的地到着予定時刻を逐次算出するものとする。目的地到着予定時刻の算出は公知のナビゲーション装置で行われる目的地到着予定時刻の算出と同様にして行う構成とすればよい。また、車両側ユニット１は、自動運転ＥＣＵ６０で生成した推奨経路での目的地到着予定時刻を、表示装置１４に表示できるものとする。

　変形例７の要否判定部１１２は、目的地到着予定時刻が例えば１０分等の一定時間以上変更された場合に、自動運転時においてドライバ動作が必要となったと判定する。一例として、直近の過去の目的地到着予定時刻の算出結果から新たな目的地到着予定時刻の算出結果が一定時間以上変更された場合に、自動運転時においてドライバ動作が必要となったと判定すればよい。他にも、表示装置１４に表示した直近の目的地到着予定時刻の算出結果から新たな目的地到着予定時刻の算出結果が一定時間以上変更された場合に、自動運転時においてドライバ動作が必要となったと判定してもよい。変形例７の要否判定部１１２は、目的地到着予定時刻が一定時間以上変更された場合に、変更された目的地到着予定時刻のドライバによる確認が必要となったことを示す要求通知を送信処理部１１３に出力する。

　そして、携帯端末２の表示制御部２０１では、車両側ユニット１から送信された上述の要求通知に含まれるドライバ動作の内容に応じた支援表示を表示部２１０に行わせる。変更された目的地到着予定時刻のドライバによる確認が必要となったことを示す要求通知に対しては、前述の情報提供にあたる支援表示を行うことになる。具体例としては、変更された目的地到着予定時刻を表す内容の支援表示を行う構成とすればよい。また、ドライバによる確認済みの意思伝達は、前述したように操作デバイス１２の操作，携帯端末２の操作等によって行う構成とすればよい。変形例７の構成では、車両側ユニット１から携帯端末２へ要求通知を送信する際に、変更された目的地到着予定時刻も送信し、携帯端末２で支援表示を行う場合に、この目的地到着予定時刻も表示する構成とすればよい。

　なお、自車が交差点近辺に位置するか否かにかかわらず、変形例３で述べたようにしてＨＣＵ１１で緊急車両の接近を検出した場合に、要否判定部１１２が、自動運転時においてドライバ動作が必要となったと判定する構成としてもよい。この場合、要否判定部１１２は、緊急車両接近を知らせる通知のドライバによる確認が必要となったことを示す要求通知を送信処理部１１３に出力すればよい。そして、携帯端末２の表示制御部２０１では、前述の情報提供にあたる支援表示として、緊急車両接近を知らせる内容の支援表示を行う構成とすればよい。

　（変形例８）
　なお、変形例１～７を組み合わせる構成としてもよい。また、実施形態１及び変形例１～７に示した例に限らず、自動運転時においてドライバの操作が必要となるあらゆる状況に対して、本開示は適用可能である。

　（変形例９）
　また、実施形態１及び変形例１～７を組み合わせる構成とした場合において、複数種類の支援表示の表示タイミングが重なった場合には、一例として以下のようにすればよい。支援表示の種類は、前述したように、制御関係要求、制御関係提案、非制御関係提案、及び情報提供の４種類とする。また、優先度の高いものから順に、制御関係要求，制御関係提案，非制御関係提案，情報提供であるものとする。

　表示制御部２０１は、複数種類の支援表示の表示タイミングが重なった場合には、優先度の高い種類の支援情報を優先して表示する構成とすればよい。これにより、優先度の高い種類の支援情報ほど優先してドライバの目にとまるようにすることができる。

　優先の一例としては、優先度の高い種類の支援情報を先に表示する構成とすればよい。具体的には、表示タイミングが重なった支援表示のうち、優先度の最も高い種類の支援表示のみを表示する。そして、その支援表示が終了した場合に、表示タイミングが重なった支援表示のうち次に優先度の高い種類の支援表示のみを表示するといった処理を繰り返す構成とすればよい。優先の他の例としては、表示タイミングが重なった支援表示を同時にそれぞれ異なる表示領域に表示するものの、優先度が高い種類の支援表示ほど大きく表示する構成としてもよい。

　また、表示領域が共通の種類の支援情報の表示タイミングが重なった場合には、優先度の高い種類の支援情報を先に表示する一方、表示領域が異なる種類の支援情報の表示タイミングが重なった場合には、優先度の高い種類の支援情報ほど大きく表示する構成としてもよい。ここで、この構成の一例について図１８を用いて説明を行う。図１８のＮが携帯端末２の表示画面を示しており、Ｏ，Ｑがそれぞれ異なる表示領域を示している。また、図１８のＰが制御関係要求の表示を示しており、Ｒが非制御関係提案の表示を示している。

　表示領域Ｏが、制御関係要求を表示する表示領域であり、表示領域Ｑが、制御関係提案，非制御関係提案，情報提供を表示する表示領域である。制御関係要求は、ドライバに必ず実施してもらわなくてはならない要求を行うための支援表示であるので、目立つように大きく表示する（図１８のＰ参照）。一方、制御関係提案，非制御関係提案，情報提供は、ドライバに必ずしも実施してもらわなくてもよい提案，情報提供を行うための支援表示であるので、制御関係要求よりも小さく表示する。制御関係要求と、表示領域Ｑに表示する支援表示との表示タイミングが重なった場合にも、制御関係要求の方を大きく表示するので、制御関係要求の方が目立つことになる。なお、制御関係要求を表示させる場合に、表示領域Ｑに支援表示を表示させない構成としてもよい。

　また、制御関係提案，非制御関係提案，情報提供は、表示領域Ｑが共通であるので、表示タイミングが重なった場合には、優先度の高い種類の支援情報を先に表示する。非制御関係提案と情報提供との表示タイミングが重なった場合には、非制御関係提案を先に表示することになる（図１８のＲ参照）。これにより、制御関係提案，非制御関係提案，情報提供のうちの優先度の高い支援表示ほど先にドライバの目にとまるようになる。図１８で例を示す構成によれば、優先度の最も高い支援表示を大きく表示する表示領域を確保して最も目立つようにしつつ、優先度がより低い種類の支援表示の群についても、優先度がより高いものは先に表示することで少ない表示領域を有効に活用することができる。

　（実施形態２）
　実施形態１及び変形例１～９では、車両側ユニット１と携帯端末２とが近距離無線通信によって情報をやり取りする構成を示したが、必ずしもこれに限らない。例えば、車両ＨＶの外部の機器を介して間接的に接続して通信を行うことにより情報をやり取りする構成（以下、実施形態２）としてもよい。

　以下、本開示の実施形態２の構成の一例について説明する。図１９に示すように、実施形態２の支援システム３は、車両側ユニット１ａ、携帯端末２ａ、及びサーバ装置４を含む。車両側ユニット１ａは、ＨＭＩシステム１０の代わりにＨＭＩシステム１０ａを含む点と通信機２０の代わりに通信機２０ａを含む点とを除けば、実施形態１の車両側ユニット１と同様である。携帯端末２ａは、主制御部２００の代わりに主制御部２００ａを備える点と、通信部２３０の代わりに通信部２３０ａを備える点とを除けば、実施形態１の携帯端末２と同様である。

　車両側ユニット１ａと携帯端末２ａとは、サーバ装置４を介して間接的に接続して通信を行う。車両側ユニット１ａ及び携帯端末２ａとサーバ装置４とは、携帯電話網，インターネット等の公共通信網を介して通信を行う構成とすればよい。サーバ装置４は、車両側ユニット１ａから受信した情報を携帯端末２ａに送信する一方、携帯端末２ａから受信した情報を車両側ユニット１ａに送信する。このサーバ装置４が車両の外部の機器に相当する。

　まず、図２０を用いて、車両側ユニット１ａの概略構成を説明する。車両側ユニット１ａは、ＨＭＩシステム１０ａ、通信機２０ａ、ＡＤＡＳロケータ３０、車両制御ＥＣＵ４０、周辺監視センサ５０、及び自動運転ＥＣＵ６０を含んでいる。ＨＭＩシステム１０ａは、ＨＣＵ１１の代わりにＨＣＵ１１ａを備える点を除けば、実施形態１のＨＭＩシステム１０と同様である。

　通信機２０ａは、サーバ装置４と公衆通信網を介した通信を行うための通信モジュールである。通信機２０ａは、サーバ装置４から受信した情報を車内ＬＡＮに出力するとともに、車内ＬＡＮを介してＨＣＵ１１ａから送信されてきた情報をサーバ装置４へ送信する。

　ＨＣＵ１１ａは、図２１に示すように、接続判定部１１１ａ、要否判定部１１２、送信処理部１１３、受信処理部１１４、及び提示制御部１１５を備えている。ＨＣＵ１１ａは、接続判定部１１１の代わりに接続判定部１１１ａを備えている点を除けば、実施形態１のＨＣＵ１１と同様である。接続判定部１１１ａは、通信機２０の状態をモニタし、サーバ装置４を介して携帯端末２と接続可能か否かを判定する。

　続いて、図２２を用いて、携帯端末２ａの概略構成を説明する。携帯端末２ａは、主制御部２００ａ、表示部２１０、操作入力部２２０、及び通信部２３０ａを備えている。主制御部２００ａは、機能ブロックとして表示制御部２０１ａ、操作判定部２０２、及び車両内判定部２０３を備えている。主制御部２００ａは、表示制御部２０１の代わりに表示制御部２０１ａを備える点と車両内判定部２０３を備える点とを除けば、実施形態１の主制御部２００と同様である。

　通信部２３０ａは、サーバ装置４を介して車両側ユニット１ａの通信機２０ａと通信を行う。通信部２３０ａは、通信機２０ａから要求通知を受信した場合に、受信した要求通知を主制御部２００ａに出力する。また、通信部２３０ａは、主制御部２００ａから携帯操作情報が出力された場合に、この情報を通信機２０ａへ送信する。

　車両内判定部２０３は、携帯端末２ａが車両内で用いられているか否かを判定する。一例として、携帯端末２ａがＧＰＳ機能等の測位機能を有している場合には、以下のようにすればよい。例えば、車両内判定部２０３は、この測位機能によって逐次検出した自端末の位置の時間変化量から自端末の移動速度を算出する。そして、算出した移動速度が閾値以上であった場合に、携帯端末２ａが車両内で用いられていると判定する。ここで言うところの閾値とは、歩行及び自転車による移動では検出されない程度に高い速度とすればよい。他の例としては、携帯端末２ａを車両ＨＶに持ち込んだことを示す操作入力を操作入力部２２０で受け付けた場合に、車両内判定部２０３が、携帯端末２ａが車両内で用いられていると判定する構成としてもよい。

　実施形態２の操作判定部２０２は、車両内判定部２０３で携帯端末２ａが車両内で用いられていると判定している場合であって、且つ、通信部２３０から出力される要求通知を取得した場合に、自端末が操作中か否かを判定する。一方、車両内判定部２０３で携帯端末２ａが車両内で用いられていないと判定している場合、若しくは通信部２３０から出力される要求通知を取得していない場合には、自端末が操作中か否かを判定しない。これにより、携帯端末２ａが車両内で用いられていない場合にまで、携帯端末２ａで支援表示が行われることを防ぐことが可能になる。

　実施形態２の構成であっても、要求通知を車両側ユニット１ａから携帯端末２ａが受信した場合であって、且つ、携帯端末２ａで自端末が操作中と判定した場合に、支援表示を携帯端末２ａの表示部２１０で行う。よって、実施形態１の構成と同様に、ドライバが車両ＨＶに持ち込んだ携帯端末２ａの操作を行っている場合であっても、自動運転時において必要となったドライバ動作の実行をよりスムーズに行わせることが可能になる。

　（変形例１０）
　前述の実施形態及び変形例では、携帯端末２，２ａが、要求通知を受信した場合に、操作判定部２０２での判定結果を車両側ユニット１，１ａへ送信する構成を示したが、必ずしもこれに限らない。例えば、携帯端末２，２ａで要求通知を受信した場合に、操作判定部２０２での判定結果（つまり、携帯操作情報）を携帯端末２，２ａから車両側ユニット１，１ａへ送信しない構成（以下、変形例１０）としてもよい。

　変形例１０を採用する場合には、車両側ユニット１，１ａのＨＣＵ１１，１１ａにおける携帯機操作情報を用いた処理を省略する構成とすればよい。つまり、携帯端末２，２ａを操作中か否かに関わらず、支援提示を行わせる構成とすればよい。この場合、提示制御部１１５は、要否判定部１１２でドライバによる操作が必要となったと判定した場合であって、且つ、接続判定部１１１，１１１ａで携帯端末２，２ａと接続可能でないと判定した場合に、支援提示を行わせる構成とすればよい。また、要否判定部１１２でドライバによる操作が必要となったと判定した場合であって、且つ、接続判定部１１１，１１１ａで携帯端末２，２ａと接続可能であると判定した場合には、支援提示を行わせない構成とすればよい。

　（変形例１１）
　前述の実施形態及び変形例では、提示制御部１１５が、接続判定部１１１，１１１ａで携帯端末２，２ａと接続可能であると判定されたか否かによって、支援提示を行うか否かを変更する構成を示したが、必ずしもこれに限らない。例えば、車両側ユニット１，１ａの通信機２０，２０ａと携帯端末２，２ａとが接続可能か否かに関わらず、支援提示を行わせる構成としてもよい。この場合、ＨＣＵ１１，１１ａは接続判定部１１１，１１１ａを備えない構成としてもよい。

　また、通信機２０，２０ａと携帯端末２，２ａとが接続可能か否かに関わらず表示装置１４からの支援提示は行わせる一方、通信機２０，２０ａと携帯端末２，２ａとが接続可能であるか否かに応じて音声出力装置１５からの支援提示を行うか否かは変更する構成としてもよい。詳しくは、通信機２０，２０ａと携帯端末２，２ａとが接続可能である場合には、音声出力装置１５からの支援提示を行わせない一方、通信機２０，２０ａと携帯端末２，２ａとが接続可能でない場合には音声出力装置１５からの支援提示を行わせる構成とすればよい。これは、携帯端末２，２ａを操作中のドライバにとって、表示装置１４からの支援提示は目につきにくいためにわずらわしさが生じにくいが、音声出力装置１５からの支援提示は耳に入るためにわずらわしさが生じやすいと考えられるためである。

　（実施形態３）
　前述の実施形態及び変形例では、携帯端末２が操作中か否かを携帯端末２で判定する構成を示したが、必ずしもこれに限らない。例えば、車両側ユニット１で判定する構成（以下、実施形態３）としてもよい。

　以下、本開示の実施形態３の構成の一例について説明する。実施形態３の支援システム３は、車両側ユニット１、及び携帯端末２ｂを含む。実施形態３の車両側ユニット１は、ＨＣＵ１１の代わりにＨＣＵ１１ａを含む点を除けば、実施形態１の車両側ユニット１と同様である。携帯端末２ｂは、主制御部２００の代わりに主制御部２００ｂを備える点と、操作判定部２０２の代わりに操作情報取得部２０４を備える点とを除けば、実施形態１の携帯端末２と同様である。

　まず、図２３を用いて、携帯端末２ｂの概略構成を説明する。携帯端末２ｂは、主制御部２００ｂ、表示部２１０、操作入力部２２０、及び通信部２３０を備えている。主制御部２００ｂは、機能ブロックとして表示制御部２０１ｂ及び操作情報取得部２０４を備えている。主制御部２００ｂは、表示制御部２０１の代わりに表示制御部２０１ｂを備える点と、操作判定部２０２を備えない代わりに操作情報取得部２０４を備える点とを除けば、実施形態１の主制御部２００と同様である。

　操作情報取得部２０４は、通信部２３０から出力される要求通知を取得した場合に、携帯端末２ｂが操作中か否かをＨＣＵ１１ｂで判定できる情報（以下、判定用情報）を取得する。判定用情報の一例としては、表示制御部２０１がスリープモードに移行しているか否かの情報，操作入力部２２０で操作入力を受け付けているか否かの情報等がある。

　表示制御部２０１ｂは、通信部２３０から出力される後述の支援指示を取得した場合に、支援表示を表示部２１０に行わせる。一方、支援指示を取得していない場合には、表示制御部２０１ｂは支援表示を表示部２１０に行わせない。

　続いて、図２４を用いて、ＨＣＵ１１ｂの概略構成を説明する。ＨＣＵ１１ｂは、要否判定部１１２、送信処理部１１３ｂ、受信処理部１１４ｂ、提示制御部１１５ｂ、及び操作判定部１１６を備えている。ＨＣＵ１１ｂは、送信処理部１１３、受信処理部１１４、及び提示制御部１１５の代わりに送信処理部１１３ｂ、受信処理部１１４ｂ、及び提示制御部１１５ｂを備える点と、接続判定部１１１を備えない代わりに操作判定部１１６を備える点とを除けば、実施形態１のＨＣＵ１１と同様である。

　送信処理部１１３ｂは、要求通知を要否判定部１１２から取得した場合に、通信機２０から携帯端末２ｂへ要求通知を送信させる。また、送信処理部１１３ｂは、提示制御部１１５ｂから支援表示を行わせる指示（以下、支援指示）を取得した場合に、この支援指示を通信機２０から携帯端末２ｂへ送信させる。この送信処理部１１３ｂが指示処理部に相当する。

　受信処理部１１４ｂは、通信機２０で携帯端末２ｂから送信される判定用情報を受信した場合に、この判定用情報を取得して、操作判定部１１６に出力する。この受信処理部１１４ｂが判定情報取得部に相当する。操作判定部１１６は、受信処理部１１４から判定用情報が出力されてきた場合に、この判定用情報をもとに携帯端末２ｂが操作中か否かを、操作判定部２０２と同様にして判定する。

　提示制御部１１５ｂは、操作判定部１１６で携帯端末２ｂが操作中であると判定した場合に、支援指示を送信処理部１１３ｂに出力する。一方、操作判定部１１６で携帯端末２ｂが操作中でないと判定した場合には、支援指示を送信処理部１１３ｂに出力しない。こにより、操作判定部１１６で携帯端末２ｂが操作中であると判定した場合には、支援指示が携帯端末２ｂへ送信され、携帯端末２ｂの表示部２１０に支援表示が行われることになる。

　また、提示制御部１１５ｂは、要否判定部１１２でドライバによる操作が必要となったと判定した場合に、条件に応じて支援提示を行わせる。一例としては、送信処理部１１３ｂから要求通知を送信させてから所定時間経過しても、判定用情報を受信処理部１１４ｂで受信できない場合に、表示装置１４及び／又は音声出力装置１５で支援提示を行わせる。ここで言うところの所定時間とは、通信機２０と携帯端末２ｂとが接続されている場合における、要求通知に応じて判定用情報を返信するのにかかる時間よりも長い時間とすればよい。提示制御部１１５ｂは、操作判定部１１６で携帯端末２ｂが操作中でないと判定した場合にも、表示装置１４及び／又は音声出力装置１５で支援提示を行わせる。一方、操作判定部１１６で携帯端末２ｂが操作中であると判定した場合には、表示装置１４及び／又は音声出力装置１５で支援提示を行わせない。

　実施形態２の構成であっても、要求通知を車両側ユニット１ａから携帯端末２ａが受信した場合であって、且つ、携帯端末２ａが操作中とＨＣＵ１１ｂで判定した場合に、支援表示を携帯端末２ａの表示部２１０で行う。よって、実施形態１の構成と同様に、ドライバが車両ＨＶに持ち込んだ携帯端末２ａの操作を行っている場合であっても、自動運転時において必要となったドライバ動作の実行をよりスムーズに行わせることが可能になる。

　（変形例１２）
　前述の実施形態及び変形例では、表示装置１４だけでなく音声出力装置１５からも支援提示を行わせる構成を示したが、必ずしもこれに限らない。例えば、音声出力装置１５からは支援提示を行わせない構成としてもよい。

　ここで、この出願に記載されるフローチャート、あるいは、フローチャートの処理は、複数のセクション（あるいはステップと言及される）から構成され、各セクションは、たとえば、Ｓ１と表現される。さらに、各セクションは、複数のサブセクションに分割されることができる、一方、複数のセクションが合わさって一つのセクションにすることも可能である。さらに、このように構成される各セクションは、デバイス、モジュール、ミーンズとして言及されることができる。

　本開示は、実施例に準拠して記述されたが、本開示は当該実施例や構造に限定されるものではないと理解される。本開示は、様々な変形例や均等範囲内の変形をも包含する。加えて、様々な組み合わせや形態、さらには、それらに一要素のみ、それ以上、あるいはそれ以下、を含む他の組み合わせや形態をも、本開示の範疇や思想範囲に入るものである。

Claims

　加速、制動、及び操舵を自動で制御する自動運転を行うとともに、前記自動運転時においてドライバによる操作、回答、及び確認の少なくともいずれかであるドライバ動作が必要となることがある車両で用いられる車載装置（１１，１１ａ，１１ｂ，２０，２０ａ）と、
　前記車両のドライバに携行されるとともに前記車載装置と接続して通信を行う携帯端末（２，２ａ，２ｂ）とを含み、
　前記車載装置及び前記携帯端末のいずれかは、前記携帯端末が操作中か否かを判定する操作判定部（２０２，１１６）を備え、
　前記携帯端末は、前記自動運転時において前記ドライバ動作が必要となった場合であって、且つ、前記操作判定部で前記携帯端末が操作中と判定した場合に、前記自動運転時において必要となった前記ドライバ動作の実行を支援する旨の支援表示を行う表示部（２１０）を備える支援システム。
　請求項１において、
　前記車載装置（１１，１１ａ，２０，２０ａ）は、前記自動運転時において前記ドライバ動作が必要となった場合であって、且つ、前記携帯端末と接続可能である場合に、前記ドライバ動作が必要となったことを示す要求通知を前記携帯端末に送信させる通知処理部（１１３）を備え、
　前記携帯端末は、前記操作判定部（２０２）を備えるものであり、
　前記操作判定部は、前記要求通知を前記携帯端末で受信した場合に、前記携帯端末が操作中か否かを判定し、
　前記表示部は、前記操作判定部で前記携帯端末が操作中と判定した場合に、前記支援表示を行う支援システム。
　請求項１において、
　前記車載装置（１１ｂ，２０）は、
　前記自動運転時において前記ドライバ動作が必要となった場合であって、且つ、前記携帯端末と接続可能である場合に、前記携帯端末が操作中か否かを判定できる判定用情報を前記携帯端末から取得する判定情報取得部（１１４ｂ）と、
　前記操作判定部（１１６）とを備え、
　前記操作判定部は、前記判定情報取得部で取得した前記判定用情報をもとに前記携帯端末が操作中か否かを判定するものであり、
　前記操作判定部で前記携帯端末が操作中と判定した場合に、前記支援表示を行わせる指示を前記携帯端末に送信させる指示処理部（１１３ｂ）をさらに備え、
　前記携帯端末（２ｂ）の前記表示部は、前記指示処理部によって送信された前記指示を前記携帯端末で受信した場合に、前記支援表示を行う支援システム。
　請求項１～３のいずれか１項において、
　前記車載装置（１１，１１ｂ，２０）と前記携帯端末（２，２ｂ）とは直接的に接続して近距離無線通信を行う支援システム。
　請求項２において、
　前記車載装置（１１ａ，２０ａ）と前記携帯端末（２ａ）とは前記車両の外部の機器（４）を介して間接的に接続して通信を行うものであり、
　前記携帯端末は、
　前記携帯端末が車両内で用いられているか否かを判定する車両内判定部（２０３）を備え、
　前記操作判定部は、前記要求通知を前記携帯端末で受信した場合であって、且つ、前記車両内判定部で前記携帯端末が車両内で用いられていると判定した場合に、前記携帯端末が操作中か否かを判定する支援システム。
　請求項１～５のいずれか１項において、
　前記支援表示としては、優先度の高いものから順に、車両制御についてドライバへの操作の要求を行うものである制御関係要求、車両制御についてドライバへの提案を行うものである制御関係提案、ドライバへ車両制御に関わらない提案を行うものである非制御関係提案、及びドライバへ情報の提供を行うものである情報提供の少なくともいずれかを含み、
　前記表示部は、複数種類の前記支援表示の表示タイミングが重なった場合には、前記優先度の高いものを優先して表示する支援システム。
　請求項６において、
　前記表示部は、前記制御関係要求と前記制御関係要求以外の種類の前記支援表示とを同時に表示する場合には、前記制御関係要求を、前記制御関係要求以外の種類の前記支援表示よりも大きく表示する支援システム。
　請求項７において、
　前記表示部は、前記制御関係要求以外の種類の前記支援表示を表示する表示領域が同じものであって、前記制御関係要求以外の種類の前記支援表示を同時に表示する場合には、前記優先度の高いものから先に表示する支援システム。
　請求項１～８のいずれか１項において、
　前記自動運転時において前記ドライバ動作が必要となる場合とは、前記自動運転からドライバが手動で運転操作を行う手動運転に切り替わる場合を少なくとも含むものであり、
　前記表示部は、前記自動運転から前記手動運転に切り替わる場合であって、且つ、前記操作判定部で前記携帯端末が操作中と判定した場合に、前記自動運転から前記手動運転への運転交代を支援する旨の前記支援表示を行う支援システム。
　請求項１～９のいずれか１項において、
　前記自動運転時において前記ドライバ動作が必要となる場合とは、前記自動運転時においてドライバによる回答若しくは確認が必要となる場合を少なくとも含むものであり、
　前記表示部は、前記操作判定部で前記携帯端末が操作中と判定した場合に、ドライバに回答若しくは確認を求める問い合わせを支援する旨の前記支援表示を行う支援システム。
　請求項１～１０のいずれか１項において、
　前記車載装置は、
　音声出力装置から音声を出力させる音声出力処理部（１１５）を備え、
　前記音声出力処理部は、前記自動運転時において前記ドライバ動作が必要となった場合に、前記携帯端末と接続可能でない場合には、前記自動運転時において必要となった前記ドライバ動作の実行を支援する旨の音声を出力させる一方、
　前記音声出力処理部は、前記自動運転時において前記ドライバ動作が必要となった場合に、前記携帯端末と接続可能であって、且つ、前記操作判定部で前記携帯端末が操作中と判定した場合には、前記自動運転時において必要となった前記ドライバ動作の実行を支援する旨の音声を出力させない支援システム。
　車両のドライバに携行される携帯端末であって、
　加速、制動、及び操舵を自動で制御する自動運転を行うとともに、前記自動運転時においてドライバによる操作、回答、及び確認の少なくともいずれかであるドライバ動作が必要となることがある前記車両で用いられ、前記自動運転時において前記ドライバ動作が必要となった場合に前記ドライバ動作が必要となったことを示す要求通知を送信させる車載装置（１１，２０，１１ａ，２０ａ）と接続して通信を行う通信部（２３０，２３０ａ）と、
　前記要求通知を前記通信部で受信した場合に、自端末が操作中か否かを判定する操作判定部（２０２）と、
　前記操作判定部で前記携帯端末が操作中と判定した場合に、前記自動運転時において必要となった前記ドライバ動作の実行を支援する旨の支援表示を行う表示部（２１０）とを備える携帯端末。
　加速、制動、及び操舵を自動で制御する自動運転を行うとともに、前記自動運転時においてドライバによる操作、回答、及び確認の少なくともいずれかであるドライバ動作が必要となることがある車両で用いられ、前記車両のドライバに携行される携帯端末（２ｂ）と接続して通信を行う車載装置（１１ｂ，２０）であって、
　前記自動運転時において前記ドライバ動作が必要となった場合であって、且つ、前記携帯端末と接続可能である場合に、前記携帯端末が操作中か否かを判定できる判定用情報を前記携帯端末から取得する判定情報取得部（１１４ｂ）と、
　前記判定情報取得部で取得した前記判定用情報をもとに前記携帯端末が操作中か否かを判定する操作判定部（１１６）と、
　前記操作判定部で前記携帯端末が操作中と判定した場合に、前記自動運転時において必要となった前記ドライバ動作の実行を支援する旨の支援表示を行わせる指示を前記携帯端末に送信させる指示処理部（１１３ｂ）とを備える車載装置。