JP2021157595A - 走行支援システム、走行支援方法およびプログラム - Google Patents

Abstract

【課題】障害の情報を適切に通知する走行支援システムを提供する。【解決手段】走行支援システムでは、車両の走行における障害因子を認識し、その障害因子に接近する接近車両の情報を取得する。障害因子の情報に基づいて、取得された接近車両の種類の情報に応じた警告情報を生成し、生成された警告情報を接近車両に送信する。警告情報に基づき、接近車両の搭乗者への通知又は接近車両の走行制御、又はその両方を行う。【選択図】図８

Description

本発明は、走行を支援する走行支援システム、走行支援方法およびプログラムに関する。

特許文献１には、自車の周囲を走行中の他車に搭載されたカメラの位置・向き・視野角・移動速度の検出を常時行うことで、運転者の死角領域を最も良い条件下で撮像できるカメラの選択を行うことが記載されている。この技術によると、最も良い条件下で撮像できるカメラにより、走行環境を検出できる。

特開２００７−１６４５４９号公報

しかしながら、検出された状況が車両にとっての障害となり得るか否かは、その車両によって異なる。例えば、二輪車両にとって障害となり得えても、四輪車両にとって障害となり得ないケースがある。従って、検出された状況を障害情報として一律に通知してしまうと、その障害情報を受信した車両は、例えば、必ずしも障害でないことを障害であると認識してしまうなど、障害の判定を適切に行うことができない。

本発明は、障害の情報を適切に通知する走行支援システム、走行支援方法およびプログラムを提供することを目的とする。

本発明に係る走行支援システムは、車両の走行を支援するサーバを含む走行支援システムであって、前記車両の走行における障害因子を認識する認識手段と、前記障害因子に接近する接近車両の情報を取得する取得手段と、前記認識手段により認識された前記障害因子の情報に基づいて、前記取得手段により取得された前記接近車両の種類の情報に応じた警告情報を生成する生成手段と、前記警告情報を前記接近車両に送信する送信手段と、前記警告情報に基づき、前記接近車両の搭乗者への通知又は前記接近車両の走行制御、又はその両方を行う制御手段とを備えることを特徴とする。

本発明に係る走行支援方法は、車両の走行を支援するサーバを含む走行支援システムにおいて実行される走行支援方法であって、前記車両の走行における障害因子を認識する認識工程と、前記障害因子に接近する接近車両の情報を取得する取得工程と、前記認識工程において認識された前記障害因子の情報に基づいて、前記取得工程において取得された前記接近車両の種類の情報に応じた警告情報を生成する生成工程と、前記警告情報を前記接近車両に送信する送信工程と、前記警告情報に基づき、前記接近車両の搭乗者への通知又は前記接近車両の走行制御、又はその両方を行う制御工程と、を有することを特徴とする。

本発明に係るプログラムは、コンピュータを、車両の走行における障害因子を認識する認識手段、前記障害因子に接近する接近車両の情報を取得する取得手段、前記認識手段により認識された前記障害因子の情報に基づいて、前記取得手段により取得された前記接近車両の種類の情報に応じた警告情報を生成する生成手段、前記警告情報を前記接近車両に送信する送信手段、前記警告情報に基づき、前記接近車両の搭乗者への通知又は前記接近車両の走行制御、又はその両方を行う制御手段、として機能させる。

本発明によれば、障害の情報を適切に通知することができる。

走行支援システムの構成を示す図である。 走行支援システムの他の構成を示す図である。 走行支援システムの他の構成を示す図である。 サーバのブロック構成を示す図である。 車両のブロック構成を示す図である。 鞍乗り型車両のブロック構成を示す図である。 シーンを示す図である。 サーバにおいて実行される処理を示すフローチャートである。 Ｓ１０３の障害因子の判定処理を示すフローチャートである。 サーバにおいて実行される処理を示すフローチャートである。 通知データの生成処理を示すフローチャートである。 通知データの生成処理を示すフローチャートである。

以下、添付図面を参照して実施形態を詳しく説明する。尚、以下の実施形態は特許請求の範囲に係る発明を限定するものではなく、また実施形態で説明されている特徴の組み合わせの全てが発明に必須のものとは限らない。実施形態で説明されている複数の特徴のうち二つ以上の特徴が任意に組み合わされてもよい。また、同一若しくは同様の構成には同一の参照番号を付し、重複した説明は省略する。

［第１実施形態］
図１は、本実施形態における走行支援システムの構成を示す図である。走行支援システム１００は、走行支援サービスを提供するサーバ１０１、サーバ１０１と接続された基地局１１０、１１３を含む。走行支援システム１００は、車両１０４、１１１を含み、本実施形態では、車両１０４、１１１は四輪車両である。しかしながら、車両１０４、１１１は、四輪車両に限られず、例えば、鞍乗り型車両、もしくは特殊用途向けの車両であっても良い。鞍乗り型車両は、二輪でも良く、三輪でも良いが、本実施形態では、鞍乗り型二輪車両として説明する。また、走行支援システム１００は、通信端末１１２を含む。通信端末１１２は、ＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）機能を含む、外部との通信機能を備えた通信装置である。本実施形態では、鞍乗り型車両１１４の搭乗者が通信端末１１２として、例えばスマートフォンを保持している。また、通信端末１１２により実現される通信機能は、鞍乗り型車両１１４に含まれていても良い。本実施形態では、通信端末１１２は、スマートフォンとして説明するが、例えば、他の通信装置として、鞍乗り型車両１１４の搭乗者のヘルメットであっても良い。車両１０４は、基地局１１０との間での無線通信を介して、サーバ１０１と相互に通信可能である。車両１１１、通信端末１１２は、基地局１１３との間での無線通信を介して、サーバ１０１と相互に通信可能である。また、鞍乗り型車両１１４と通信端末１１２の間は相互に通信可能であっても良く、例えば、鞍乗り型車両１１４は、通信端末１１２を介してサーバ１０１と通信可能であっても良く、鞍乗り型車両１１４が直接サーバ１０１と通信可能であっても良い。

本実施形態では、車両１０４、１１１、通信端末１１２に対応する鞍乗り型車両１１４は、建物や、信号機や路側機等の公共設備が存在する一般的な道路を走行しているケースを想定する。そのようなケースにおいては、例えば、道路上の凹凸や水たまり、道路に飛び出す可能性のある自転車、歩行者等の移動体、など、様々な種類の走行の障害因子が発生し得る。それらの障害因子は、車両のタイプによっては、重大な障害因子となる場合があれば、走行には影響のない場合もある。例えば、水たまりや窪み、路面の凍結は、鞍乗り型車両にとっては、その影響が大きい一方、四輪車両にとっては、走行に影響がない場合がある。本実施形態では、障害因子を認識した場合、車両のタイプに応じて、適切に障害因子の搭乗者に対する通知を行う。

図１の建物１０２は、例えば道路脇に存在する建物であり、公共設備１０３は、信号機や路側機等の公共設備である。建物１０２、公共設備１０３は、道路の脇道を監視する監視カメラ等の撮像部１０５、１０６を備えている。撮像部１０５で撮像された撮像データは、画像処理され、ネットワーク（ＮＷ）１０８を介してサーバ１０１に送信される。また、撮像部１０６で撮像された撮像データは、画像処理され、ネットワーク１０９を介してサーバ１０１に送信される。また、車両１０４は、外部環境を認識するためのカメラ等の撮像部１０７を備えており、撮像部１０７で撮像された撮像データは、画像処理され、基地局１１０との間の無線通信を介してサーバ１０１に送信される。

図７（ａ）（ｂ）は、図１、及び後述する図２、図３の構成に対応するシーンの一例を示す図である。図７（ａ）の車両７０２及び撮像部７０３は、図１の車両１０４及び撮像部１０７に対応する。また、建物７０４及び撮像部７０５は、図１の建物１０２及び撮像部１０５に対応する。また、撮像部７０６は、例えば路側機に設けられたカメラを表しており、図１の公共設備１０３の撮像部１０６に対応する。また、障害因子７０７は、例えば道路上の窪みである。また、車両７０１は、鞍乗り型車両であり、その搭乗者の保持するもしくは車両７０１に取り付けられた通信装置は、図１の通信端末１１２に対応する。図７（ｂ）は、さらに、車両７０１の後方に車両７０８が走行しているシーンを示しており、車両７０８は、図１の車両１１１に対応する。

図２は、走行支援システム１００の他の構成を示す図である。図２は、サーバ１０１の構成がない点で図１と異なる。図２では、建物１０２の撮像部１０５で撮像された撮像データは、基地局１３１を介して車両１０４に送信される。また、公共設備１０３の撮像部１０６で撮像された撮像データは、基地局１３２を介して車両１０４に送信される。車両１０４の制御部１２０は、それらの撮像データもしくは車両１０４の撮像部１０７で撮像された撮像データから障害因子を認識すると、車両１１１、通信端末１１２に対して、障害因子の情報の送信を行う。

図３は、走行支援システム１００の他の構成を示す図である。図３は、車両１１１と端末１１２に、制御部１２１、１２２が構成されている点で図２と異なる。制御部１２１、１２２は、プロセッサ、メモリを含むコンピュータシステムであり、車両の場合には例えばＥＣＵを含むコントローラであり、通信端末１１２の場合には例えばＣＰＵを含むコントローラである。図３では、車両１１１の制御部１２１および通信端末１１２の制御部１２２は、車両１０４から送信された障害因子の情報と自車両との関連性について判断し、その判断結果に基づいて搭乗者への通知を行う。関連性の判断に基づく通知の動作については、第３実施形態において説明する。

図４は、サーバ１０１のブロック構成を示す図である。制御部４００は、サーバ１０１を統括的に制御する。制御部４００は、制御部４００内の動作を統括的に制御するＣＰＵやＧＰＵ等のプロセッサ４０１、メモリ４０２、撮像データ取得部４０３、画像認識部４０４、判定部４０５、通知データ生成部４０６、通知データ送信部４０７、車両情報取得部４０８、挙動予測部４０９を含むコンピュータシステムである。本実施形態におけるサーバ１０１の動作は、例えば、プロセッサ４０１がメモリ４０２上でプログラムを実行することにより実現される。撮像データ取得部４０３は、建物１０２、公共設備１０３や車両１０４から送信された撮像データを受信する。本実施形態では、この撮像データには、例えば、障害因子として道路上の窪みが撮像されている。画像認識部４０４は、例えば、クラス分類等の手法を用いて、撮像データ取得部４０３により取得された撮像データ上でオブジェクトを認識する。

判定部４０５は、画像認識部４０４の認識結果に基づいて、車両の走行にとっての障害因子であるかを判定する。障害因子の判定処理については後述する。通知データ生成部４０６は、車両１１１や通信端末１１２に対して送信する通知データを生成する。通知データ送信部４０７は、通知データ生成部４０６により生成された通知データを車両１１１や通信端末１１２に対して送信する。車両情報取得部４０８は、車両１１１や通信端末１１２から送信された車両情報を取得する。車両情報には、例えば、各車両で取得されたＧＰＳ情報が含まれる。また、車両情報取得部４０８は、車両１１１の搭乗者、通信端末１１２の保持者によりアプリケーションを介して予め登録された車両の車種等の車両情報を取得可能である。挙動予測部４０９は、通知データを送信する対象となる車両が障害因子を回避する経路を予測する。挙動予測部４０９の動作については、第３実施形態において説明する。

記憶部４２０は、サーバ１０１が動作するためのプログラムやデータ、および本実施形態の動作で必要なプログラムやデータを記憶する。また、記憶部４２０は、地図情報４２１、環境情報４２２を記憶する。地図情報４２１は、例えば地図データベースであり、環境情報４２２は、例えば気象情報データベースや路面情報データベースである。なお、地図情報４２１、環境情報４２２は、記憶部４２０内に構成されずに、外部のデータベースサーバから取得するようにしても良い。記憶部４２０は、他の情報を記憶しても良く、例えば、通信端末１１２のユーザ情報と、車両情報（ＧＰＳ情報や車種等）とを互いに対応づける情報を記憶しても良い。

表示部４３０は、例えばディスプレイであり、サーバ１０１のユーザに対して、各種ユーザインタフェース画面を表示する。操作部４３１は、ユーザからの操作を受付可能であり、例えば、キーボードやポインティングデバイスである。通信インタフェース（Ｉ／Ｆ）４３２は、基地局１１０、１１３、ネットワーク１０８、１０９との間の通信を可能とする。サーバ１０１は、図４に示すブロック構成に限られず、例えば、サーバ１０１の機能に応じた機能ブロックを適宜含む。なお、図４では、サーバ１０１は１つの装置として示されているが、複数の装置で構成されても良い。即ち、本実施形態におけるサーバ１０１は、１つの装置でサーバ機能を提供する構成、複数の装置で連携してサーバ機能を提供する構成、を含む。

図５は、車両１０４及び車両１１１のブロック構成を示す図である。以下、車両１０４と車両１１１の代表例として車両１０４を説明する。制御部５００は、外界認識部５０１、自己位置認識部５０２、車内認識部５０３、行動計画部５０４、駆動制御部５０５、デバイス制御部５０６、通信制御部５０７を含む。各ブロックは、１つのＥＣＵ、若しくは、複数のＥＣＵにより実現される。

外界認識部５０１は、外界認識用カメラ５０８及び外界認識用センサ５０９からの信号に基づいて、車両１０４の外界情報を認識する。外界認識用カメラ５０８は、図１の車両１０４の撮像部１０７に対応する。外界認識部５０１は、外界認識用カメラ５０８及び外界認識用センサ５０９からの信号に基づいて、例えば、交差点や踏切、トンネル等のシーン、路肩等のフリースペース、他車両の挙動（速度や進行方向等）を認識する。自己位置認識部５０２は、ＧＰＳ５１２からの信号に基づいて車両１０４の現在位置を認識する。

車内認識部５０３は、車内認識用カメラ５１０及び車内認識用センサ５１１からの信号に基づいて、車両１０４の搭乗者を識別し、また、搭乗者の状態を認識する。車内認識用カメラ５０８は、例えば、車両１０４の車内の表示装置５１７上に設置された近赤外カメラであり、例えば、搭乗者の視線の方向を検出する。また、車内認識用センサ５１１は、例えば、搭乗者の生体信号を検知するセンサである。車内認識部５１１は、それらの信号に基づいて、搭乗者の居眠り状態、運転以外の作業中の状態、であることなどを認識する。

行動計画部５０４は、外界認識部５０１、自己位置認識部５０２による認識の結果に基づいて、最適経路、リスク回避経路など、車両１０４の行動を計画する。行動計画部５０４は、例えば、交差点や踏切等の開始点や終点に基づく進入判定、他車両の挙動の予測結果に基づく行動計画を行う。駆動制御部５０５は、行動計画部５０４による行動計画に基づいて、駆動力出力装置５１３、ステアリング装置５１４、ブレーキ装置５１５を制御する。

デバイス制御部５０６は、制御部５００に接続されるデバイスを制御する。例えば、デバイス制御部５０６は、スピーカ５１６を制御し、警告やナビゲーションのためのメッセージ等、所定の音声メッセージを出力させる。また、例えば、デバイス制御部５０６は、表示装置５１７を制御し、所定のインタフェース画面を表示させる。また、例えば、デバイス制御部５０６は、ナビゲーション装置５１８を制御し、ナビゲーション装置５１８での設定情報を取得する。通信制御部５０７は、通信装置５１９を介して外部と通信可能であり、例えば、他の車両の通信装置から情報を受信可能である。

制御部５００は、図５に示す以外の機能ブロックを適宜含んでも良く、例えば、通信装置５１９を介して取得した地図情報に基づいて目的地までの最適経路を算出する最適経路算出部を含んでも良い。また、制御部５００は、ＧＰＳ５１２だけでなく、車両１０４に設けられた各種センサからの検知信号を受信可能である。例えば、制御部５００は、車両１０４のドア部に設けられたドアの開閉センサやドアロックの機構センサの検知信号を、ドア部に構成されたＥＣＵを介して受信する。それにより、制御部５００は、ドアのロック解除や、ドアの開閉動作を検知することができる。

図６（ａ）は、通信端末１１２に対応する鞍乗り型車両１１４のブロック構成を示す図である。ＥＣＵ（Ｅｌｅｃｒｏｎｉｃ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）６１０は、鞍乗り型車両１１４の各部を統括的に制御する。鞍乗り型車両１１４は、例えば、スロットルバイワイヤ（ｔｈｒｏｔｔｌｅ ｂｙ ｗｉｒｅ）方式で走行制御が行われる構成であり、ＥＣＵ６１０は、操舵部６１３のアクセス開度の電気信号を受けてスロットルバルブを開閉することにより、エンジンを含む駆動部６１１を制御する。制動部６１２は、ブレーキ機構を含む。センサ群６１４は、速度センサ、スロットルセンサ、大気圧センサ等の各種センサを含み、ＥＣＵ６１０は、それらの検知信号を受信する。通知部６１５は、ランプ、ＬＥＤ等を含み、例えば、障害因子が存在する方向（左右等）を表示する点灯機構である。

制御部６００は、通信インタフェース（Ｉ／Ｆ）６０４を介して通信端末１１２との間での無線通信を実行可能なブロックである。なお、通信Ｉ／Ｆ６０４は、基地局１１３との間での無線通信が可能なように構成されても良い。制御部６００は、制御部６００内の動作を統括的に制御するプロセッサ６０１、メモリ６０２、通知制御部６０３、通信Ｉ／Ｆ６０４を含むコンピュータシステムである。本実施形態における鞍乗り型車両１１４の動作は、例えば、プロセッサ６０１がメモリ６０２上でプログラムを実行することにより実現される。通知制御部６０３は、通信端末１１２から送信された通知制御データに基づいて、通知部６１５の制御をＥＣＵ６１０に要求する。例えば、通知制御部６０３は、通信端末１１２から送信された通知制御データをＥＣＵ６１０が処理可能な信号に変換し、ＥＣＵ６１０に送信する。本実施形態では、通知とは、パネルへの表示、ランプの点灯、ハンドルの振動など鞍乗り型車両１１４の搭乗者に対して認識させるための処理をいう。例えば、通知制御部６０３は、通知部６１５のランプを表示させるための通知制御データや、操舵部６１３のハンドルを振動させるための通知制御データをＥＣＵ６１０が処理可能な信号に変換し、ＥＣＵ６１０に送信する。また、制御部６００は、ＵＳＢ等の記憶部６１６と接続可能である。鞍乗り型車両１１４は、図６（ａ）に示すブロック構成に限られず、例えば、鞍乗り型車両１１４の機能に応じた機能ブロックを適宜含む。例えば、鞍乗り型車両１１４は、鞍乗り型車両１１４のＧＰＳ情報を取得するＧＰＳと、ＧＰＳ情報や速度情報等を車両情報として外部に送信可能な車両情報送信部とを含むように構成しても良い。

図６（ｂ）は、通信端末１１２のブロック構成を示す図である。制御部６２０は、通信端末１１２を統括的に制御する。制御部６２０は、制御部６２０内の動作を統括的に制御するプロセッサ６２１、メモリ６２２を含むコンピュータシステムである。本実施形態における通信端末１１２の動作は、例えば、プロセッサ６２１がメモリ６２２上でプログラムを実行することにより実現される。ＧＰＳ情報送信部６２３は、ＧＰＳ６３４により取得されたＧＰＳ情報を通信Ｉ／Ｆ６３３を介して外部に送信する。表示制御部６２４は、表示部６３１での表示を制御する。通知制御データ送信部６２５は、外部から送信された通知制御データに基づいて、鞍乗り型車両１１４で用いられる通知制御データを生成し、通信Ｉ／Ｆ６３３を介して鞍乗り型車両１１４へ送信する。例えば、通知制御データは、図６（ａ）の通知部６１５に含まれるランプを点灯させる点灯制御データや、鞍乗り型車両１１４の搭乗者のヘルメットに対して視覚的、聴覚的に通知するためのデータである。

記憶部６３０は、通信端末１１２が動作するためのプログラムやデータ、および本実施形態の動作で必要なプログラムやデータを記憶する。例えば、サーバ１０１により提供されるアプリケーションが記憶部６３０に記憶される。例えば、通信端末１１２のユーザは、そのアプリケーションを起動し、設定画面上で、サーバ１０１への登録、鞍乗り型車両１１４の制御部６００とのペアリングを行う。表示部６３１は、例えばタッチパネルであり、通信端末１１２のユーザに対して、各種ユーザインタフェース画面を表示する。なお、本実施形態では、通信端末１１２のユーザは、鞍乗り型車両１１４の搭乗者に対応する。操作部６３２は、ユーザからの操作を受付可能であり、ハードキー、タッチパネル上に表示されるソフトキーを含む。ＧＰＳ６３４は、通信端末１１２の現在位置を検出するための位置検出機構である。通信Ｉ／Ｆ６３３は、外部との無線通信を可能とする。なお、通信Ｉ／Ｆ６３３は、通信距離が異なる複数の無線通信に対応するように構成されても良い。通信端末１１２は、図６（ｂ）に示すブロック構成に限られず、例えば、通信端末１１２の機能に応じた機能ブロックを適宜含む。

本実施形態では、通信端末１１２に対応する車両は鞍乗り型車両１１４であるとして説明するが、他のタイプの車両、例えば四輪車両であっても良い。その場合、四輪車両のＥＣＵと図６（ｂ）の制御部６２０が四輪車両に一体的に構成されるようにしても良い。

図８は、サーバ１０１において実行される処理を示すフローチャートである。図８の処理は、図１の構成の場合、サーバ１０１で実行されるが、図２及び図３の構成の場合、車両１０４において実行される。以下の説明では、サーバ１０１において実行されるとして説明する。図８の処理は、例えば、プロセッサ４０１がメモリ４０２上でプログラムを実行することにより実現される。

Ｓ１０１において、プロセッサ４０１は、撮像データ取得部４０３により、撮像データを取得する。ここで、取得される撮像データは、建物１０２の撮像部１０５で撮像された撮像データ、公共設備１０３の撮像部１０６で撮像された撮像データ、車両１０４の撮像部１０７で撮像された撮像データの少なくともいずれかである。

Ｓ１０２において、プロセッサ４０１は、環境情報４２２から環境情報を取得する。ここで、取得される環境情報は、例えば、降雪といった気象情報や、路面の凍結情報である。Ｓ１０３において、プロセッサ４０１は、障害因子の判定を行う。

図９は、Ｓ１０３の障害因子の判定処理を示すフローチャートである。Ｓ２０１において、プロセッサ４０１は、画像認識部４０４により、障害因子の認識を行い、Ｓ２０２において、判定部４０５により、Ｓ２０１の認識結果に基づいて、車両の走行路面上に障害因子があるか否かを判定する。例えば、撮像データ上の濃度や輝度の変化に基づいて、走行路面上の水たまりや窪みが認識され、障害因子として判定される。その際に、Ｓ１０２で取得された環境情報による推定を用いるようにしても良い。Ｓ２０２で走行路面上に障害因子があると判定された場合、Ｓ２０３に進み、プロセッサ４０１は、判定部４０５により、障害因子ありと判定し、その判定結果をメモリ４０２等の記憶領域に格納する。その後、図９の処理を終了する。一方、走行路面上に障害因子がないと判定された場合、２０４に進む。

Ｓ２０４において、プロセッサ４０１は、判定部４０５により、Ｓ２０１の認識結果に基づいて、車両の走行路面外、例えば歩道に移動体があるか否かを判定する。ここで、移動体とは、例えば、自転車や歩行者等である。Ｓ２０４で走行路面外に移動体がないと判定された場合、Ｓ２０８に進み、プロセッサ４０１は、判定部４０５により障害因子なしと判定し、その判定結果をメモリ４０２等の記憶領域に格納する。その後、図９の処理を終了する。一方、走行路面外に移動体があると判定された場合、Ｓ２０５に進む。

Ｓ２０５において、プロセッサ４０１は、画像認識部４０４により、Ｓ２０４で判定された移動体の挙動分析を行う。例えば、Ｓ２０５では、移動体のサイズと、その移動体の移動方向が分析される。

Ｓ２０６において、プロセッサ４０１は、判定部４０５により、Ｓ２０５の分析結果に基づいて、車両の走行路面外に障害因子があるか否かを判定する。例えば、Ｓ２０５での分析の結果、移動体のサイズが所定値以上であり且つ所定方向への移動であると推定される場合には、車両の走行路面外に障害因子があると判定される。ここでの所定方向とは、例えば、歩道から走行路へ向かう方向である。Ｓ２０６で走行路面外に障害因子があると判定された場合、Ｓ２０７に進み、プロセッサ４０１は、判定部４０５により、障害因子ありと判定し、その判定結果をメモリ４０２等の記憶領域に格納する。その後、図９の処理を終了する。一方、例えば、Ｓ２０５での分析の結果、移動体のサイズが所定値未満であるか、所定方向への移動でないと推定される場合には、車両の走行路面外に障害因子がないと判定される。Ｓ２０６で走行路面外に障害因子がないと判定された場合、Ｓ２０８に進み、プロセッサ４０１は、判定部４０５により、障害因子なしと判定し、その判定結果をメモリ４０２等の記憶領域に格納する。その後、図９の処理を終了する。

このように、例えば、風に吹かれて移動している小さなビニール袋や、走行路面から遠ざかる方向に移動している歩行者は、障害因子として認識されないので、障害因子を適切に認識することができる。

Ｓ２０３の後、図９の処理を終了しているが、Ｓ２０３の後、Ｓ２０４〜Ｓ２０８の処理を行うようにしても良い。その場合、路面外に移動体ありか否かの判定結果をＳ２０３での判定結果と識別可能に記憶する。

再び、図８を参照する。Ｓ１０３の後、Ｓ１０４において、プロセッサ４０１は、判定部４０５により、図９のＳ２０３、Ｓ２０７、Ｓ２０８でメモリ４０２等の記憶領域に格納された結果に基づいて、障害因子があるか否かを判定する。障害因子がないと判定された場合、Ｓ１０１からの処理を繰り返す。一方、障害因子があると判定された場合、Ｓ１０５に進む。

Ｓ１０５において、プロセッサ４０１は、車両情報取得部４０８により、その障害因子を含む所定の範囲に車両が存在するか否かを判定する。例えば、プロセッサ４０１は、各車両から送信されるＧＰＳ情報に基づいて、障害因子を中心とする所定の範囲に車両が存在するか否かを判定するようにしても良い。Ｓ１０５で所定の範囲に車両が存在しないと判定された場合、図８の処理を終了する。一方、所定の範囲に車両が存在すると判定された場合、Ｓ１０６に進む。

Ｓ１０６において、プロセッサ４０１は、車両情報取得部４０８により、所定の範囲に存在すると判定された車両の車両情報を取得する。例えば、四輪車両や鞍乗り型車両といった車両のタイプが車両情報として取得される。

Ｓ１０７において、プロセッサ４０１は、通知データ生成部４０６により、通知データを生成する。本実施形態では、プロセッサ４０１は、Ｓ１０６で取得された車両のタイプに応じた通知データを生成する。例えば、Ｓ１０６で取得された車両のタイプが鞍乗り型車両である場合には、「前方に窪みがあります。回避して下さい。」といった回避を促すメッセージを含む通知データを生成する。一方、Ｓ１０６で取得された車両のタイプが四輪車両である場合には、「前方に窪みがあります。」のように、障害因子の存在を通知するものの、回避を促すメッセージを含まない通知データを生成する。車両のタイプに応じて通知データを異ならせる基準として、例えば、障害因子が、窪みや凍結など走行路面上の状態を示す場合には、鞍乗り型車両に対しては、障害因子の存在だけでなく、その回避を促すメッセージを加えるというようにしても良い。また、障害因子が走行路面外での移動体である場合には、車両のタイプによらず一律としても良い。上記の基準情報は、記憶部４２０に予め記憶するようにしても良い。

Ｓ１０８において、プロセッサ４０１は、通知データ送信部４０７により、Ｓ１０７で生成された通知データをＳ１０５で存在すると判定された車両に対して送信する。その後、図８の処理を終了する。通知データを受信した車両１１１、通信端末１１２は、通知データに基づいて搭乗者に対して通知を行う。その通知は、例えば、車両１１１の表示装置５１７に表示されるものであっても良いし、スピーカ５１６から発話されるものであっても良い。また、通信端末１１２の表示部６３１に表示されるものであっても良い。また、通信端末１１２は、通知データに基づいて、通信端末１１２の保持者が搭乗する鞍乗り型車両１１４の制御部６００に通知制御データを送信し、駆動部６１１、制動部６１２、操舵部６１３や通知部６１５を制御することで、搭乗者に対する通知が行われても良い。

以上のように、本実施形態によれば、同じ障害因子であっても、車両のタイプに応じて、障害因子の通知データを異ならせる。そのような構成により、例えば、障害因子が窪みである場合、鞍乗り型車両に対しては、回避を促すメッセージを通知データとして送信することにより、その搭乗者に対して回避を促すことができる。また、四輪車両に対しては、窪みの存在のみを搭乗者に対して通知するメッセージを通知データとして送信することにより、過剰な回避行為となってしまうことを防ぐことができる。

また、本実施形態では、四輪車両と鞍乗り型車両とで通知データを異ならせる例を説明したが、四輪車両と鞍乗り型車両に限られない。例えば、普通自動車と大型特殊自動車といったように、そのサイズ、車輪数等に応じて異ならせるようにしても良い。その場合、それらの情報は、車両情報として取得される。

また、本実施形態では、障害因子を含む所定の範囲に存在する車両に対して、通知データを送信するとして説明した。ここで、通知データを送信する必要のない車両に対しては、通知データを送信しないようにしても良い。例えば、障害因子が窪みである場合、その窪みのサイズが所定値以下であると認識された場合、四輪車両の走行に及ぼす影響度が極めて低いと判定し、Ｓ１０７において、四輪車両に対しては通知データを生成しないようにしても良い。そのような構成により、通信量を低減させることができる。

また、本実施形態では、図８のＳ１０８で通知データを送信する際、送信先の車両の接近状況に合わせて、通知データの送信タイミングを制御するようにしても良い。例えば、通知データを送信する対象の車両から受信するＧＰＳ情報から移動速度を算出し、障害因子から所定の距離に達する際に搭乗者に対して通知されるよう通知データを送信する。そのような構成により、例えば、搭乗者に対して通知されるタイミングが遅いために、障害因子の回避が間に合わなくなってしまう事態を防ぐことができる。

また、本実施形態では、通知データによる搭乗者に対する通知として、例えば、メッセージの表示や発話、ランプの点灯を挙げて説明した。しかしながら、そのような例に限られず、走行支援動作等の車両の走行制御が搭乗者に対する通知とともに行われても良い。例えば、自動ブレーキを作動させるようにしても良い。また、通知データによる搭乗者に対する通知の内容を、ユーザが走行支援システム１００を利用する前に予め、サーバ１０１のアプリケーション上で設定可能としても良い。

［第２実施形態］
以下、第２実施形態について第１実施形態と異なる点について説明する。第１実施形態では、障害因子が発生した場合、その障害因子を搭乗者に対して通知するための通知データを、周辺に位置する各車両のタイプに応じて異ならせ、搭乗者に対する適切な通知を行うことを説明した。ここで、図７（ｂ）を参照しながら、本実施形態の動作について説明する。

障害因子７０７が発生すると、第１実施形態で説明したように、その障害因子を搭乗者に対して通知するための通知データが鞍乗り型車両７０１と四輪車両７０８に対して送信される。ここで、鞍乗り型車両７０１が障害因子７０７を回避するために、右側に走行経路を変更していくことが想定される。そのケースにおいて、四輪車両７０８がそもそも右側に車線変更していくことを予定しているのであれば、鞍乗り型車両７０１の回避行動そのものが四輪車両７０８にとっての障害因子となり得る。そこで、本実施形態では、四輪車両７０８に対して、障害因子７０７をその搭乗者に対して通知するための情報とともに、鞍乗り型二輪車両７０１が回避行動をとる可能性があることを示す情報を合わせて送信する。

図１０は、サーバ１０１において実行される処理を示すフローチャートである。図１０の処理は、図１の構成の場合、サーバ１０１で実行されるが、図２及び図３の構成の場合、車両１０４において実行される。以下の説明では、サーバ１０１において実行されるとして説明する。図１０の処理は、例えば、プロセッサ４０１がメモリ４０２上でプログラムを実行することにより実現される。

Ｓ３０１〜Ｓ３０４は、図８のＳ１０１〜Ｓ１０４における説明と同じであるので、その説明を省略する。

Ｓ３０５において、プロセッサ４０１は、車両情報取得部４０８により、その障害因子を含む第１の範囲に車両が存在するか否かを判定する。例えば、プロセッサ４０１は、各車両から送信されるＧＰＳ情報に基づいて、障害因子を中心とする第１の範囲に車両が存在するか否かを判定するようにしても良い。Ｓ３０５で第１の範囲に車両が存在しないと判定された場合、図１０の処理を終了する。一方、第１の範囲に車両が存在すると判定された場合、Ｓ３０６に進む。本実施形態では、第１の範囲に存在すると判定された車両を第１の車両とし、図７（ｂ）の鞍乗り型車両７０１に対応する。

Ｓ３０６において、プロセッサ４０１は、プロセッサ４０１は、車両情報取得部４０８により、第１の範囲に存在すると判定された車両の車両情報を取得する。ここでは、四輪車両や鞍乗り型車両といった車両のタイプが車両情報として取得される。

Ｓ３０７において、プロセッサ４０１は、通知データ生成部４０６により、通知データを生成する。そして、Ｓ３０８において、プロセッサ４０１は、通知データ送信部４０７により、Ｓ３０７で生成された通知データをＳ３０５で存在すると判定された車両に対して送信する。

Ｓ３０９において、プロセッサ４０１は、判定部４０５により、Ｓ３０５で第１の範囲に存在すると判定された第１の車両が障害因子７０７を回避する必要があるか否かを判定する。Ｓ３０９では、プロセッサ４０１は、障害因子７０７の情報と車両のタイプとが予め対応づけられた情報に基づいて判定するようにしても良い。例えば、障害因子のサイズが所定範囲内である場合には、鞍乗り型車両は回避が必要であり、四輪車両は回避が不要であると対応づけられても良い。Ｓ３０９で第１の車両が障害因子を回避する必要がないと判定された場合、図１０の処理を終了する。一方、第１の車両が障害因子を回避する必要があると判定された場合、Ｓ３１０に進む。

Ｓ３１０において、プロセッサ４０１は、車両情報取得部４０８により、その障害因子７０７を含む第２の範囲に車両（第２の車両）が存在するか否かを判定する。ここで、第２の範囲は、第１の範囲よりも広く設定されている。即ち、図７（ｂ）の車両７０８のように、Ｓ３０５で存在すると判定される第１の車両よりも後方に位置する車両が、Ｓ３０８で第２の車両として判定される。Ｓ３０９で第２の範囲に車両が存在しないと判定された場合、図１０の処理を終了する。一方、第２の範囲に車両が存在すると判定された場合、Ｓ３１１に進む。

Ｓ３１１において、プロセッサ４０１は、通知データ生成部４０６により、第２の車両に対して送信する通知データを生成する。そして、Ｓ３１２において、プロセッサ４０１は、通知データ送信部４０７により、Ｓ３１１で生成された通知データをＳ３１０で存在すると判定された車両に対して送信する。

図１１（ａ）は、Ｓ３１１における通知データの生成処理を示すフローチャートである。Ｓ４０１において、プロセッサ４０１は、通知データ生成部４０６により、第２の車両の障害因子７０７を回避する挙動を予測する。例えば、挙動の予測として、回避経路が予測される。そして、Ｓ４０２において、プロセッサ４０１は、通知データ生成部４０６により、Ｓ４０１で予測された挙動に基づいて、第２の車両に送信する通知データを生成する。その後、図１１（ａ）の処理を終了する。

図１１（ｂ）は、Ｓ４０２で生成される通知データに基づいて、表示装置５１７に表示される画面の一例を示す図である。図１１（ｂ）の画面１１０１上の表示領域１１０２には、第２の車両の前方に位置する車両のイメージ画像が表示される。障害因子１１０６は、Ｓ３０３で判定された障害因子であり、図７（ｂ）の障害因子７０７に対応する。車両１１０５は、図７（ｂ）の車両７０２に対応する。車両１１０４は、Ｓ３０５で第１の範囲に存在すると判定された第１の車両であり、図７（ｂ）の車両７０１に対応する。経路１１０７は、Ｓ４０１で予測された第２の車両の障害因子の回避経路である。表示領域１１０３には、「前方のバイクが障害物を回避する可能性があります！」という前方の車両が回避行動をとる可能性がある旨のメッセージが表示される。上記のメッセージの「バイク」の部分は、車両１１０４の車両のタイプに応じたワードが挿入される。

図１１（ｂ）の画面１１０１が表示されることにより、第１の車両の後方を走行する第２の車両の搭乗者に対して、前方の第１の車両が回避行動をとることを通知することができる。

以上のように、本実施形態によれば、障害因子を回避する必要があると判定された第１の車両の後方を走行する第２の車両の搭乗者に対して、第１の車両の回避行動の可能性を通知することができる。そのような構成により、第１の車両の回避行動が第２の車両の搭乗者にとって意図せぬ突然の行動となってしまうことを防ぐことができる。

［第３実施形態］
以下、第３実施形態について第１及び第２実施形態と異なる点について説明する。第１実施形態では、障害因子が発生した場合、その障害因子を搭乗者に対して通知するための通知データを、周辺に位置する各車両のタイプに応じて異ならせ、搭乗者に対する適切な通知を行うことを説明した。本実施形態では、障害因子の情報を含む通知データは、各車両のタイプに関わらず、一律に送信される。そして、通知データを受信した車両１１１もしくは通信端末１１２において、障害因子の情報の自車両に対する関連度を判断し、搭乗者に対する通知が必要なデータであると判定された場合には通知を行い、搭乗者に対する通知が必要でないデータであると判定された場合には通知を行わない。そのような構成により、通知データの送信側における処理の負荷を低減させることができる。

第１実施形態で説明したように、図３は、車両１１１と端末１１２に、制御部１２１、１２２が構成されている点で図２と異なる。制御部１２１、１２２は、プロセッサ、メモリを含むコンピュータシステムであり、車両の場合には例えばＥＣＵを含むコントローラであり、通信端末１１２の場合には例えばＣＰＵを含むコントローラである。図３では、車両１１１の制御部１２１および通信端末１１２の制御部１２２は、車両１０４から送信された障害因子の情報と自車両との関連性について判断し、その判断結果に基づいて搭乗者への通知を行う。

図１２は、通知データを受信した車両１１１もしくは端末１１２において実行される処理を示すフローチャートである。図１２の処理は、例えば、図３の車両１１１の制御部１２１、端末１１２の制御部１２２により実行される。以下、制御部１２１が実行するとして説明するが、制御部１２２についても同様である。また、図１２の処理は、図８のＳ１０８で通知データが送信された後に実行される。なお、図８のＳ１０７では、第１実施形態と異なり、障害因子７０７の情報が通知データとして各車両のタイプに関わらず一律に生成される。障害因子７０７の情報として、例えば、障害因子７０７のサイズ、移動体の有無、を含む。移動体の有無の情報については、例えば、図９の処理においてＳ２０３の後もＳ２０４〜Ｓ２０８の処理を行うようにし、その処理結果に基づいて生成されるようにしても良い。

Ｓ５０１において、制御部１２１は、通知データを受信したか否かを判定する。Ｓ５０１は、通知データを受信したと判定されるまで繰り返される。通知データを受信したと判定された場合、Ｓ５０２に進む。

Ｓ５０２において、制御部１２１は、障害因子７０７の情報に基づいて、受信した通知データの自車両への関連度を判断する。例えば、制御部１２１は、障害因子７０７のサイズが搭乗者に対する通知を要する所定範囲に含まれる場合には、関連度が高いと判断する。その所定範囲は車両のタイプにより異なり、例えば、閾値より小さい所定範囲の領域が鞍乗り型車両において搭乗者に対する通知を要するサイズの所定範囲であり、閾値以上が四輪車両において搭乗者に対する通知を要するサイズの所定範囲として定められても良い。また、例えば、自車両の移動経路と、路面外の移動体の走行路への移動経路とが、自車両の接近に伴い、重なる確度が高いと判断される場合には、関連度が高いと判断する。

Ｓ５０３において、制御部１２１は、Ｓ５０２で判断された関連度に基づいて、搭乗者への通知を要するか否かを判定する。Ｓ５０２で関連度が高いと判断されＳ５０３で搭乗者への通知を要すると判定された場合、Ｓ５０４に進み、通知データに基づいて搭乗者に対して通知を行う。その通知は、例えば、車両１１１の表示装置５１７に表示されるものであっても良いし、スピーカ５１６から発話されるものであっても良い。また、通信端末１１２が通知データを受信した場合には、通信端末１１２の表示部６３１に表示されても良い。その場合、通信端末１１２は、通知データに基づいて、通信端末１１２の保持者が搭乗する鞍乗り型車両１１４の制御部６００に通知制御データを送信し、駆動部６１１、制動部６１２、操舵部６１３や通知部６１５を制御することで、搭乗者に対する通知が行われても良い。その後、図１２の処理を終了する。一方、Ｓ５０３で搭乗者への通知を要さないと判定された場合、図１２の処理を終了する。

以上のように、本実施形態によれば、通知データに基づく通知の要否を、その通知データの受信側で判断する。そのような構成により、通知データの送信側における処理の負荷を低減させることができる。

Ｓ１０７の通知データの生成において、車両のタイプに応じて、搭乗者への通知の必要性の有無を示す情報を合わせて生成するようにし、その情報を含む通知データをＳ１０８で送信するようにしても良い。搭乗者への通知の必要性の有無を示す情報は、例えば、障害因子７０７のサイズと各車両のタイプに基づいて、各車両のタイプごとに生成される。そして、Ｓ５０２において、制御部１２１は、搭乗者への通知の必要性を示す情報が「通知を要する」と示されている場合には、自車両への関連度が高いと判断する。このように、受信側での搭乗者への通知の要否を識別可能にする通知データを生成して送信することにより、受信側での自車両への関連度の判断処理をより簡易にすることができる。

＜実施形態のまとめ＞
上記実施形態の走行支援システムは、車両の走行を支援するサーバを含む走行支援システムであって、前記車両の走行における障害因子を認識する認識手段（４０４）と、前記障害因子に接近する接近車両の情報を取得する取得手段（４０８）と、前記認識手段により認識された前記障害因子の情報に基づいて、前記取得手段により取得された前記接近車両の種類の情報に応じた警告情報を生成する生成手段（４０６）と、前記警告情報を前記接近車両に送信する送信手段（４０７）と、前記警告情報に基づき、前記接近車両の搭乗者への通知又は前記接近車両の走行制御、又はその両方を行う制御手段とを備えることを特徴とする。

そのような構成により、例えば、障害因子へ接近する車両のタイプに応じて、適切な障害情報を通知することができる。また、前記生成手段は、前記障害因子のサイズが所定値以上又は以下であることを判定し、判定結果に応じて、前記接近車両の車種に応じた警告情報を生成することを特徴とする。

そのような構成により、例えば、障害因子へ接近する鞍乗り型車両と四輪車両との間で、通知データの内容を異ならせたり、一方には通知データを送信しないように制御することができる。

また、そのような構成により、例えば、道路上の窪みの径が所定値以上である場合に、鞍乗り型車両には、回避動作が必要であることを加えて警告することができる。

前記警告情報に基づいて、前記制御手段による制御を行うか否かの判定と、該制御の内容の決定との少なくともいずれか一方を行う制御決定手段、をさらに備え、前記制御決定手段は、前記障害因子の情報と前記接近車両との関連度を評価し、当該評価結果に基づき、前記制御手段による制御を行うか否かの判定と、該制御の内容の決定との少なくともいずれか一方を行うことを特徴とする。

そのような構成により、例えば、警告情報に基づいて、接近車両の搭乗者に対して通知するか否かの判定を行うことができる。

また、前記接近車両は、第１の接近車両と、前記第１の接近車両よりも後方に位置する第２の接近車両とを含み、前記第１の接近車両が前記障害因子を回避すると予測される場合、前記送信手段は、前記第１の接近車両の回避経路を含む警告情報を前記第２の接近車両に送信することを特徴とする。

そのような構成により、例えば、接近車両に対して、接近車両の前方の鞍乗り型車両が障害因子を回避する可能性を通知することができる。

発明は上記の実施形態に制限されるものではなく、発明の要旨の範囲内で、種々の変形・変更が可能である。

１００ 走行支援システム： １０１ サーバ： １０２ 建物： １０３ 公共設備： １０４、１１１ 車両： １１２ 通信端末： １２０、１２１、１２２、４００、６２０ 制御部： ４０１、６２１ プロセッサ： ４０２、６２２ メモリ

Claims (6)

1. 車両の走行を支援するサーバを含む走行支援システムであって、
   前記車両の走行における障害因子を認識する認識手段と、
   前記障害因子に接近する接近車両の情報を取得する取得手段と、
   前記認識手段により認識された前記障害因子の情報に基づいて、前記取得手段により取得された前記接近車両の種類の情報に応じた 警告情報を生成する生成手段と、
   前記警告情報を前記接近車両に送信する送信手段と、
   前記警告情報に基づき、前記接近車両の搭乗者への通知又は前記接近車両の走行制御、又はその両方を行う制御手段と、
   を備えることを特徴とする走行支援システム。
2. 前記生成手段は、前記障害因子のサイズが所定値以上又は以下であることを判定し、判定結果に応じて、前記接近車両の車種に応じた警告情報を生成することを特徴とする請求項１に記載の走行支援システム。
3. 前記警告情報に基づいて、前記制御手段による制御を行うか否かの判定と、該制御の内容の決定との少なくともいずれか一方を行う制御決定手段、をさらに備え、
   前記制御決定手段は、前記障害因子の情報と前記接近車両との関連度を評価し、当該評価の結果に基づき、前記制御手段による制御を行うか否かの判定と、該制御の内容の決定との少なくともいずれか一方を行うことを特徴とする請求項１又は２に記載の走行支援システム。
4. 前記接近車両は、第１の接近車両と、前記第１の接近車両よりも後方に位置する第２の接近車両とを含み、
   前記第１の接近車両が前記障害因子を回避すると予測される場合、前記送信手段は、前記第１の接近車両の回避経路を含む警告情報を前記第２の接近車両に送信する、
   ことを特徴とする請求項１乃至３のいずれか１項に記載の走行支援システム。
5. 車両の走行を支援するサーバを含む走行支援システムにおいて実行される走行支援方法であって、
   前記車両の走行における障害因子を認識する認識工程と、
   前記障害因子に接近する接近車両の情報を取得する取得工程と、
   前記認識工程において認識された前記障害因子の情報に基づいて、前記取得工程において取得された前記接近車両の種類の情報に応じた警告情報を生成する生成工程と、
   前記警告情報を前記接近車両に送信する送信工程と、
   前記警告情報に基づき、前記接近車両の搭乗者への通知又は前記接近車両の走行制御、又はその両方を行う制御工程と、
   を有することを特徴とする走行支援方法。
6. コンピュータを、
   車両の走行における障害因子を認識する認識手段、
   前記障害因子に接近する接近車両の情報を取得する取得手段、
   前記認識手段により認識された前記障害因子の情報に基づいて、前記取得手段により取得された前記接近車両の種類の情報に応じた警告情報を生成する生成手段、
   前記警告情報を前記接近車両に送信する送信手段、
   前記警告情報に基づき、前記接近車両の搭乗者への通知又は前記接近車両の走行制御、又はその両方を行う制御手段、
   として機能させるためのプログラム。

Images