JP2018045303A - 運転支援システム - Google Patents

Abstract

【課題】ユーザが自覚せずに危険な運転操作を実施していた場面について教示することができる運転支援システムを提供する。【解決手段】運転支援システム１０００は、複数の車両の各々に搭載される車両用ユニット１とセンタ３とを備える。センタ３は、各搭載車両の挙動等を示す運転状況データをデータベースに蓄積していく。センタ３は、当該ユーザが運転していた車両の近くを走行した他の車両（つまり周辺車両）の挙動に基づいて、ユーザが危険運転を実施した場面（つまり危険運転シーン）を抽出する。そして、危険運転シーン発生直後におけるユーザの生体情報と、平常時の生体情報を比較することによって、ユーザが、危険運転を実施したことを自覚しているか否かを判定する。リクエストユーザが危険運転を実施したことを自覚していない場面（つまり無自覚危険運転シーン）が存在する場合にはその旨をユーザに通知する。【選択図】図１

Description

本発明は、運転状況を示すデータを記録しておき、その記録されたデータに基づいて注意すべき状況を検出し、ドライバに提示する運転支援システムに関する。

従来、運転状況を示すデータを記録しておき、その記録されているデータから検出される注意すべき状況をドライバに提示することによって、ドライバの運転能力の向上を図る運転支援システムが種々提案されている。

例えば特許文献１には、過去のドライバの車両運転時に収集したドライバの生体情報を用いて、ドライバの注意力が欠如している状態を検出し、ドライバに対して注意喚起を行う運転支援システムが開示されている。

具体的には、走行中におけるドライバの生体情報が、緊張やヒヤリハット等によって、平常な状態から変化した場所を注意箇所として登録しておく。そして、ドライバが同じ箇所を再び走行している場合の生体情報に、過去の走行時と同様の変化が観測されない場合には、ドライバが漫然運転等といった、所定の危険な状態であると判定して注意喚起を行う。

特開２０１１−２４２１９０号公報

特許文献１に開示の技術では、前回の走行時までに注意箇所として登録されていない箇所で、ドライバが無自覚に実行した危険な運転操作に対し、ドライバとしてのユーザに注意喚起を実施することができない。

本発明は、この事情に基づいて成されたものであり、その目的とするところは、ユーザが自覚せずに危険な運転操作を実施していた場面について教示することができる運転支援システムを提供することにある。

その目的を達成するための本発明は、第１ユーザが運転する車両で使用される装置であって、車両に搭載された生体情報センサから、車両のドライバとしての第１ユーザの生体情報を逐次取得する生体情報取得部（Ｆ２）と、車両に搭載された車両情報センサから、車両の走行状態を示す情報であって、少なくとも車両の位置情報を含む車両情報を逐次取得する車両情報取得部（Ｆ１）と、を備える車両用装置（１ａ）と、車両とは異なる移動体で使用される装置である他移動体装置から、他移動体装置を使用している人物である第２ユーザが危険を感じたか否かを判定するための指標として機能する判定用情報と、他移動体装置の位置情報とを、他移動体情報として逐次取得する他移動体情報取得部（３１、１０４）と、生体情報取得部が逐次取得する生体情報と車両情報取得部が逐次取得する車両情報とを、取得時刻と対応付けて記憶部（３２）に保存するとともに、他移動体情報取得部が逐次取得する他移動体情報を、取得時刻と対応付けて記憶部に保存する保存処理部（３３）と、記憶部に保存されている他移動体情報と車両情報に基づいて、第２ユーザが、車両の挙動に対して危険を感じたと推定される場面である危険運転シーンを検出する危険運転シーン検出部（３４３，３４４）と、危険運転シーン検出部によって検出された危険運転シーンにおいて、第１ユーザが危険運転を実施したことを自覚しているか否かを、記憶部に保存されている生体情報から判定する認識状態判定部（３４５）と、認識状態判定部が第１ユーザは危険運転シーンにおいて危険運転を実施したことを自覚していないと判定した場合には、危険運転シーンについての情報を第１ユーザに提示する提示処理部（２４）とを備えることを特徴とする。

以上の構成において保存処理部は、第１ユーザが運転している車両の車両情報と第１ユーザの生体情報とを記憶部に保存していく。また、第２ユーザによって利用されている他移動体装置から取得した他移動体情報についても保存していく。

危険運転シーン検出部は、記憶部に保存されている種々の情報に基づいて、第１ユーザが運転している車両の挙動に対して第２ユーザが危険を感じたと推定される場面（つまり危険運転シーン）を検出する。また、認識状態判定部は、記憶部に保存されている第１ユーザの生体情報に基づき、危険運転シーンにおいて第１ユーザが危険運転を実施したことを自覚しているか否かを判定する。そして、第１ユーザが自覚していない危険運転シーンが存在する場合には、提示処理部がその場面についての情報を第１ユーザに提示する。

このような構成によれば、危険運転シーンは、第１ユーザの生体情報を用いずに抽出される。そのため、仮に第１ユーザが危険運転を実施していたことに気づいていない場面についても、危険運転シーンとして抽出される。そのため、ユーザが自覚せずに危険な運転操作を実施していた場面について教示することができる。また、上記構成によれば、例えば注意箇所として登録されていない箇所や、初めて走行する箇所において、危険運転を実施した場合であっても、ユーザに対して注意喚起を実施することができる。

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

運転支援システム１０００の概略的な構成を示した図である。 車両用ユニット１の概略的な構成の一例を示すブロック図である。 車両用ユニット１の概略的な構成の一例を示すブロック図である。 運転状況報告データの構成を説明するための図である。 車両用ユニット１が実施する運転状況報告処理を説明するためのフローチャートである。 確認用端末２の概略的な構成を示すブロック図である。 確認用端末２が実施する問い合わせ処理を説明するためのフローチャートである。 センタ３の概略的な構成を示すブロック図である。 センタ３が実施する確認要求応答処理を説明するためのフローチャートである。 周辺車両抽出処理について説明するためのフローチャートである。 認識状態判定処理について説明するためのフローチャートである。 変形例における車両用ユニット１の概略的な構成を示した図である。 変形例における車両用ユニット１及びセンタ３の概略的な構成を示した図である。

以下、本発明の実施形態について図を用いて説明する。図１は、本発明に係る運転支援システム１０００の概略的な構成の一例を示す図である。図１に示すように、運転支援システム１０００は、複数の車両Ｍａ，Ｍｂ，Ｍｃの各々に搭載されている複数の車両用ユニット１と、確認用端末２と、センタ３と、を備える。

なお、図１では、便宜上、車両用ユニット１が搭載されている車両（以降、搭載車両）として、車両Ｍａ，Ｍｂ、Ｍｃの３台しか図示していないが、実際には４台以上存在する。以降において、搭載車両Ｍａ，Ｍｂ，Ｍｃに搭載されている車両用ユニット１を区別する場合、車両用ユニット１ａ、１ｂ、１ｃと記載する。

以降におけるユーザとは、車両用ユニット１が搭載された車両を保有する人物（換言すれば、車両用ユニット１を利用している人物）である。或るユーザは、搭載車両のドライバとしての役割も担う。複数のユーザは、ユーザ固有の識別情報であるユーザＩＤによって互いに識別される。

複数の車両用ユニット１のうちの１つ（例えば車両用ユニット１ａ）が請求項に記載の車両用装置に相当し、他の車両で用いられている車両用ユニット１（例えば車両用ユニット１ｂ、１ｃ）が請求項に記載の他移動体装置、特に他車両用装置に相当する。また、車両用ユニット１ａのユーザが請求項に記載の第１ユーザに相当し、車両用ユニット１ｂ、１ｃのユーザが請求項に記載の第２ユーザに相当する。

＜全体の概要＞
運転支援システム１０００は、ユーザが危険な運転操作をした場面（時刻と場所）を、そのユーザ以外が運転している搭載車両の挙動に基づいて検出し、ユーザが危険な運転操作を無自覚に実行していた場合には、その運転操作についてユーザに通知するシステムである。

搭載車両は、道路上を走行する車両である。搭載車両は、四輪自動車のほか、二輪自動車、三輪自動車等であってもよい。二輪自動車には原動機付き自転車も含まれる。本実施形態では一例として搭載車両は、四輪自動車とする。

各車両用ユニット１は、広域通信網４に無線接続可能に構成されている。ここでの広域通信網４とは、携帯電話網やインターネット等の、電気通信事業者によって提供される公衆通信ネットワークを指す。図１に示す基地局４１は、車両用ユニット１が広域通信網４に接続するための無線基地局である。

車両用ユニット１は、自分自身が用いられている車両（つまり搭載車両）の走行状態を示す車両情報と、ドライバの生体情報を含むデータ（以降、運転状況データ）を、一定時間分まとめて、基地局４１及び広域通信網４を介してセンタ３へ逐次送信する。便宜上、センタ３に送信される、複数時点での運転状況データをまとめたデータを運転状況報告データと称する。

車両情報には、搭載車両の現在位置を示す位置情報と、搭載車両の挙動を示す挙動情報が含まれる。挙動情報とは、例えば、搭載車両の進行方向や、走行速度、車両前後方向に作用する加速度、操舵角、ヨーレートなどである。また、クラクションボタンが押下された場合には、その旨を示す情報も挙動情報としてセンタ３に送信されるものとする。

もちろん、挙動情報に該当する情報の種類は、これに限らない。その他、アクセルペダルがユーザに踏み込まれている量（以降、アクセル踏込量）や、ブレーキペダルが踏み込まれている量（以降、ブレーキ踏込量）、シフトレバーのポジション、方向指示器の動作状態なども挙動情報に該当する。

生体情報は、例えばドライバの心拍数である。一般的に、人間は恐怖や危険を感じた時には心拍数の上昇といった反応をする。そのため、心拍数は、ドライバが危険な運転をしたことを自覚しているか否かの指標として機能する。なお、心拍数の代わりに脈拍数を生体情報として採用してもよい。心拍数も脈拍数も心臓の拍動数を示す情報である。

また、生体情報として、血圧、心電位、脈波、発汗量、鼻部等の温度、呼吸の深さ及び頻度等を採用してもよい。さらに、車室内カメラで撮像した顔画像や車室内マイクで収録した音声を、生体情報として採用してもよい。また、車室内カメラで撮像した顔画像から抽出される表情を示す情報を、生体情報として採用してもよい。それら複数種類の情報を生体情報として採用してもよい。

運転状況報告データには、そのデータを送信した車両（以降、送信元車両）を示す送信元情報や、当該データの生成時刻なども含まれる。送信元情報は、送信元車両に対して予め割り当てられた、他の車両と区別するための識別情報（いわゆる車両ＩＤ）である。これらの付加情報は、例えば運転状況報告データとして機能する通信パケットのヘッダ等に記載されていればよい。

センタ３は、搭載車両から送信された運転状況報告データを受信すると、その受信した運転状況報告データに示される複数の運転状況データを、車両ＩＤなどと対応付けて所定のデータベースに保存する。同一車両についての運転状況データは、例えば、最新のデータが先頭となるように時系列順にソートされて保存されればよい。

確認用端末２は、ユーザがセンタ３に対して、自分が無自覚に危険運転を実施したか否かを問い合わせるための通信端末である。確認用端末２は、ユーザがセンタ３に対して上記問い合わせを行うための操作部と、センタ３と広域通信網４を介した通信を実施するための機能と、問い合わせ結果を表示するためのディスプレイを備えていればよい。

例えば、周知のスマートフォン、タブレット端末、ウェアラブルデバイス、携帯用音楽プレーヤ、携帯用ゲーム機などを確認用端末２として採用することができる。また、確認用端末２は、車両に搭載されていても良いし、自宅やオフィス等に設置されたコンピュータであってもよい。

確認用端末２は、広域通信網４に無線接続するものであってもよいし、有線接続しているものであってもよい。なお、図１では便宜上、確認用端末２を１つしか図示していないが、複数のユーザのそれぞれに対応するように複数存在しうる。

確認用端末２は、ユーザ操作に基づいて、センタ３に対して、前回のトリップ時にユーザが無自覚に危険運転を実施したか否かを問い合わせる通信パケット（以降、確認要求パケット）を送信する。ここでのトリップとは、搭載車両が走行を開始してから駐車されるまでの一連の走行を指す。また、ここでの危険運転とは、周辺車両のドライバや歩行者といった周囲の人物が危険を感じる運転操作を指す。

確認要求パケットには、何れのユーザが問い合わせをしているかをセンタ３が特定するための要求元情報が含まれている。要求元情報は、ユーザ固有の識別情報であるユーザＩＤとすればよい。なお、他の態様として、要求元情報は車両ＩＤであってもよい。

センタ３は、確認要求パケットを受信した場合、後述する確認要求応答処理を実行することで、確認結果を示すトリップレポートを確認用端末２へ返送する。トリップレポートを受信した確認用端末２は、トリップレポートに示される内容をディスプレイに表示する。

このようにして、運転支援システム１０００は、ユーザが危険運転を実行していたことを自覚していない場面（以降、無自覚危険運転シーン）が存在する場合には、その場面についてユーザに通知する。以下、運転支援システム１０００を構成する種々の要素について順に詳細に説明する。

＜車両用ユニット１の構成について＞
まずは、搭載車両Ｍａに搭載されている車両用ユニット１ａを例にとって、車両用ユニット１の構成について述べる。なお、他の搭載車両（例えば車両Ｍｂ）に搭載されている車両用ユニット１も同様の構成となっている。便宜上、車両用ユニット１ａにとって自分自身が搭載されている車両（つまり車両Ｍａ）のことを、他の車両と区別して自車両とも記載する。

車両用ユニット１は、図２に示すように、車両挙動センサ１０１、ＧＮＳＳ受信機１０２、生体情報センサ１０３、及び広域通信部１０４のそれぞれと、車両内に構築された通信ネットワーク（つまり、ＬＡＮ：Local Area Network）を介して通信可能に接続されている。

車両挙動センサ１０１は、搭載車両の挙動を示す所定の物理状態量を検出するための車載センサである。本実施形態における搭載車両は、車両挙動センサ１０１として、車速センサ、加速度センサ、方位センサ、操舵角センサ、及びヨーレートセンサを備えるものとする。

車速センサは、搭載車両の走行速度を検出するセンサであり、加速度センサは搭載車両の車両前後方向に作用する加速度を検出するセンサである。方位センサは、自車両の絶対方位を検出するためのセンサであり、例えば、地磁気センサが用いられる。操舵角センサは、操舵角を検出するセンサであり、ヨーレートセンサは自車両の垂直軸周りの回転角速度、すなわち、ヨーレートを検出するセンサである。

各車載センサは、検出対象とする物理状態量の現在の値（つまり検出結果）を示すデータを車両用ユニット１に逐次提供する。なお、種々の車載センサの検出結果は、任意の電子制御装置（ＥＣＵ：Electronic Control Unit）等を介して車両用ユニット１に提供される構成となっていても良い。

なお、車両挙動センサ１０１として車両用ユニット１が接続されるべきセンサの種類は適宜設計されればよく、上述した全てのセンサと接続されている必要はない。また、上述した以外のセンサ、例えばアクセル踏込量を検出するアクセルセンサや、ブレーキ踏込量を検出するブレーキセンサ、シフトポジションを検出するシフトポジションセンサなどと接続されていても良い。

ＧＮＳＳ受信機１０２は、ＧＮＳＳ（Global Navigation Satellite System）を構成する測位衛星から送信された測位信号を受信することで、当該ＧＮＳＳ受信機１０２の現在位置を逐次（例えば１００ミリ秒毎に）検出するデバイスである。ＧＮＳＳ受信機１０２の検出結果は車両用ユニット１に逐次提供される。なお、ＧＮＳＳ受信機１０２が検出する現在位置は、例えば、緯度と経度で表されればよい。車両挙動センサ１０１及びＧＮＳＳ受信機１０２が請求項に記載の車両情報センサに相当する。

生体情報センサ１０３は、ドライバとしてのユーザの生体情報を検出するための車載センサである。本実施形態における搭載車両は、生体情報センサ１０３として、心拍数を計測する心拍数センサを備える。

なお、生体情報センサ１０３として車両用ユニット１が接続されるべきセンサの種類は適宜設計されればよい。例えば車両用ユニット１は、血圧、心電位、脈波、発汗量、体温などを検出対象とする生体情報センサと接続されていても良い。また、危険運転通知の提示を受けたいドライバの車両以外の車両用ユニット（１ｂ、１ｃ）には、必ずしも生体情報センサ１０３が搭載されていなくてもよい。

広域通信部１０４は、広域通信網４に無線接続し、車両用ユニット１が広域通信網４を介してセンタ３と通信するための通信モジュールである。この広域通信部１０４は、より細かい要素として、図示しないアンテナ及び送受信部を備える。

アンテナは、基地局４１との無線通信に用いられる所定の周波数帯の電波を送受信するためのアンテナである。送受信部は、アンテナで受信した信号を復調して車両用ユニット１に提供するとともに、車両用ユニット１から入力されたデータを変調してアンテナに出力し、無線送信する。

これらアンテナ及び送受信部の協働により、広域通信部１０４は、受信データを車両用ユニット１に出力するとともに、車両用ユニット１から入力されたデータを変調して外部装置（例えばセンタ３）に送信する通信モジュールとして機能する。

車両用ユニット１は、ＣＰＵ１１、ＲＡＭ１２、ＲＯＭ１３、及びこれらの構成を接続するバスラインなどを備えたコンピュータとして構成されている。ＣＰＵ１１は中央演算処理装置であり、ＲＡＭ１２は揮発性メモリであり、ＲＯＭ１３は不揮発性の記憶媒体である。ＲＯＭ１３は、電気的又は磁気的に書き換え可能な記憶媒体であることが好ましい。ＲＯＭ１３には、通常のコンピュータを車両用ユニット１として機能させるためのプログラム（以降、車両用プログラム）や車両ＩＤ等が格納されている。

なお、上述の車両用プログラムは、非遷移的実体的記録媒体（non- transitory tangible storage medium）に格納されていればよく、その具体的な記憶媒体はＲＯＭ１３に限らない。例えば車両用プログラムはフラッシュメモリに保存されていても良い。ＣＰＵ１１が車両用プログラムを実行することは、車両用プログラムに対応する方法が実行されることに相当する。

この車両用ユニット１は、ＣＰＵ１１がＲＯＭ１３に格納されている上述の車両用プログラムを実行することによって、図３に示す種々の機能を提供する。すなわち、車両用ユニット１は機能ブロックとして、車両情報取得部Ｆ１、生体情報取得部Ｆ２、送信処理部Ｆ３を備える。

なお、車両用ユニット１が備える機能ブロックの一部又は全部は、一つあるいは複数のＩＣ等を用いて（換言すればハードウェアとして）実現してもよい。また、車両用ユニット１が備える機能ブロックの一部又は全部は、ＣＰＵ１１によるソフトウェアの実行とハードウェア部材の組み合わせによって実現されてもよい。

車両情報取得部Ｆ１は、ＬＡＮを介して、車両挙動センサ１０１及びＧＮＳＳ受信機１０２から、自車両の走行状態を示す種々の情報（つまり、車両情報）を取得する。具体的には、自車両の現在位置や、走行速度、加速度、進行方向、操舵角、ヨーレートなどを取得する。車両情報取得部Ｆ１が取得した種々の情報は、検出時刻を示すタイムスタンプが付与されて、ＲＡＭ１２に一定時間保存される。ＲＡＭ１２における種々の情報は、情報の種別ごとに、最新のデータが先頭となるようにソートされて保存されればよい。タイムスタンプが請求項に記載の時刻情報に相当する。

生体情報取得部Ｆ２は、ＬＡＮを介して、生体情報センサ１０３から提供されるドライバの生体情報（具体的には心拍数）を逐次取得する。生体情報取得部Ｆ２が取得した生体情報にも、検出時刻を示すタイムスタンプが付与されてＲＡＭ１２に保存されていく。ＲＡＭ１２において生体情報は、最新のデータが先頭となるようにソートされて保存されればよい。

送信処理部Ｆ３は、ＲＡＭ１２に蓄積されている種々の情報に基づいて、所定時間毎の運転状況を示すデータ（つまり運転状況データ）を生成し、センタ３に送信する機能ブロックである。本実施形態では一例として送信処理部Ｆ３は、所定時間毎に（具体的には１００ミリ毎に）、その時点での運転状況を示す運転状況データを、各種センサの最新の検出結果を元に生成し、ＲＡＭ１２に保存する。

そして、所定の報告タイミングとなった場合に、運転状況報告データをセンタ３に送信する。運転状況報告データは、図４に示すように、運転状況報告データを前回送信した時点以降において新たに生成した複数の運転状況データを、生成時刻と対応付けて時系列に並べたデータである。つまり、運転状況報告データは、センタ３に未だ送信していない運転状況データの集合である。

図５は、運転状況報告データを送信する処理（以降、運転状況報告処理）を説明するためのフローチャートである。図５に示すフローチャートは、搭載車両の走行用電源（例えばイグニッション電源）がオンとなった場合に開始されればよい。

まず、ステップＳ１０１ではトリップの開始を示す通信パケットをセンタ３に送信して、ステップＳ１０２に移る。ステップＳ１０２では、運転状況データのセンタ３へのアップロードを実施すべきタイミング（以降、報告タイミング）であるか否かを判定する。報告タイミングとする条件は、適宜設計されればよい。ここでは一例として、所定のアップロード間隔（例えば１秒）で、運転状況データを送信するものとする。つまり、運転状況報告データを前回送信してから１秒経過した場合に、報告タイミングであると判定する。

運転状況報告データを前回送信してから未だ１秒経過していない場合には、ステップＳ１０２が否定判定されて待機状態となる。そして、運転状況データを前回送信してから１経過した場合にステップＳ１０２が肯定判定されてステップＳ１０３に移る。

ステップＳ１０３では、センタ３との通信接続が確立されているか否かを判定する。通信接続が確立していない場合には、通信接続を確立する手続きを実行する。当該手続きの結果、通信接続が確立した場合や、ステップＳ１０３に移った時点において通信接続が既に確立している場合にはステップＳ１０３が肯定判定されてステップＳ１０４に移る。一方、通信接続が確立できなかった場合にはステップＳ１０３が否定判定されてステップＳ１０２に戻る。

ステップＳ１０４では、運転状況報告データをセンタ３に送信して、ステップＳ１０５に移る。ステップＳ１０５では走行（換言すればトリップ）が完了したか否かを判定する。ここでは、イグニッション電源をオフにする操作がユーザによって実行されたことを検出した場合に、トリップが終了したと判定する。トリップがまだ終了していない場合、具体的にはイグニッション電源がオンに設定されたままである場合にはステップＳ１０５が否定判定されてステップＳ１０２に戻る。一方、トリップが終了したと判定した場合にはステップＳ１０６に移る。ステップＳ１０６では、トリップの終了を示す通信パケットをセンタ３に送信して本フローを終了する。

以上の処理を実施することによって、トリップ中の運転状況の経時的な変化を示す一連のデータが、センタ３へと送信されることとなる。

＜確認用端末２の構成について＞
次に、図６を用いて確認用端末２の構成について説明する。図６に示すように確認用端末２は、操作部２１、ディスプレイ２２、広域通信部２３、及び確認処理部２４を備える。操作部２１は、確認用端末２に対するユーザの指示操作を受け付けるためのデバイスである。ここでは一例として操作部２１は、ディスプレイ２２と一体になったタッチパネルとするが、これに限らない。他の態様として操作部２１は、キーボードやマウスなどであっても良い。

ディスプレイ２２は、確認処理部２４から入力される画像データを表示する。広域通信部２３は、確認用端末２が広域通信網に接続して種々の外部装置（例えばセンタ３）と通信するための通信モジュールである。

確認処理部２４は、ＣＰＵ、ＲＡＭ、ＲＯＭ、及びこれらの構成を接続するバスラインなどを備えたコンピュータとして構成されている。確認処理部２４は、操作部２１、ディスプレイ２２、及び広域通信部２３のそれぞれと相互通信可能に構成されている。確認処理部２４は、ユーザが操作部２１に対して、前回のトリップにおいて無自覚危険運転シーンがあったか否かを問い合わせるための操作を実行したことをトリガとして、図７に示す問い合わせ処理を実行する。

具体的には、まず、ステップＳ２０１として確認要求パケットを生成する。ここで生成される確認要求パケットには、前述の通り、要求元情報としてのユーザＩＤが含まれる。なお、ユーザが複数の車両を所有する場合には、前回のトリップにおいて使用した車両を示す情報（例えば車両ＩＤ）が含まれていることが好ましい。そして、確認要求パケットを広域通信部２３に出力することで、センタ３に送信してステップＳ２０２に移る。つまり、ステップＳ２０１では、広域通信部２３と協働して確認要求パケットをセンタ３に送信する。

ステップＳ２０２では、トリップレポートの受信を待機する。トリップレポートは、前述の通り、前回のトリップにおいて無自覚危険運転シーンがあったか否かを示すデータである。ステップＳ２０２においてトリップレポートを受信した場合にはステップＳ２０３に移る。なお、確認要求パケットを送信してから所定の応答待機時間（例えば１分）経過してもトリップレポートを受信できなかった場合には、タイムアウトとして、本フローを終了する。その場合には、センタ３からの応答が得られなかったことをディスプレイ２２に表示すればよい。ステップＳ２０３では、トリップレポートの内容をディスプレイ２２に表示して本フローを終了する。ステップＳ２０３を実行する確認処理部２４が請求項に記載の提示処理部に相当する。ステップＳ２０３では、スピーカを併用して音声でユーザにトリップレポートを説明してもよい。

＜センタ３の構成について＞
次に、センタ３の構成について説明する。センタ３は、図８に示すように、広域通信部３１、走行履歴データベース（以降、走行履歴ＤＢ）３２、保存処理部３３、確認要求対応部３４、及びパラメータ記憶部３５を備える。なお、保存処理部３３及び確認要求対応部３４は、サーバ等のコンピュータが所定のプログラムを実行することで実現されれば良い。

広域通信部３１は、広域通信網４に接続し、種々の外部装置（例えば車両用ユニット１や確認用端末２）と通信するための通信モジュールである。広域通信部３１は、センタ３を宛先とする通信パケットを受信し、その受信データの種別に応じた機能ブロックに、その受信データを提供する。

具体的には、運転状況報告データを受信した場合には、保存処理部３３に受信した運転状況報告データを提供する。また、確認要求パケットを受信した場合には、当該通信パケットが示す要求元情報を確認要求対応部３４に提供する。なお、本実施形態では一例としてセンタ３は広域通信網４に有線接続している態様とするが、これに限らない。センタ３は、広域通信網４に無線接続する構成となっていても良い。

なお、車両用ユニット１ａを請求項に記載の車両用装置とする場合には、車両用ユニット１ｂなどの、車両用ユニット１ａ以外の車両用ユニット１から送信されてくる運転状況データが、請求項に記載の他移動体情報に相当する。そのため、広域通信部３１が請求項に記載の他移動体情報取得部に相当する。

走行履歴ＤＢ３２は、書き換え可能な不揮発性の記憶媒体を用いて実現されるデータベースである。走行履歴ＤＢ３２は、保存処理部３３等によるデータの書き込み、読出、削除等が実施可能に構成されている。走行履歴ＤＢ３２には、ユーザ毎のユーザＩＤが、そのユーザが利用する車両に割り当てられている車両ＩＤと対応付けられて保存されている。

また、走行履歴ＤＢ３２には、複数の搭載車両のそれぞれから逐次送信されてくる運転状況データが、保存処理部３３によって車両ＩＤ毎に区別されて保存される。或る車両についての運転状況データは、当該車両の走行履歴を示すデータとしても機能する。そのため、或る車両に対応付けられている全ての運転状況データのことを、その車両の走行履歴データとも称する。

保存処理部３３は、広域通信部３１が受信した運転状況報告データに収容されている複数の運転状況データを、送信元の車両ＩＤ及びユーザＩＤと対応付けて走行履歴ＤＢ３２に保存する。同一の搭載車両についての運転状況データは、最新の運転状況データが先頭となるように時系列順に並べたリスト形式で保存していく。これにより、車両毎の走行履歴データが随時更新されていく。

また、保存処理部３３は各搭載車両の走行履歴データを、さらに、トリップ毎に区別して保存する。換言すれば、１つのトリップについての一連の運転状況データを１まとまりのデータとして取り扱う。便宜上、１つのトリップについての一連の運転状況データのことをトリップ経緯データと称する。１つのトリップについての一連の運転状況データは、当該トリップ中における搭載車両の挙動やドライバの生体情報の推移を示すデータ、つまり当該トリップの経緯を示すデータとして機能するためである。

確認要求対応部３４は、ユーザからの確認要求に基づいて、当該ユーザが前回実施したトリップにおいて無自覚危険運転シーンがあったか否かを判定し、無自覚危険運転シーンがあった場合にはその旨を報告する処理（以降、確認要求応答処理）を実行する。

確認要求対応部３４は、より細かい機能ブロックとして、リクエスト車両特定部３４１、周辺車両データ抽出部３４２、危険遭遇シーン抽出部３４３、因果関係判定部３４４、認識状態判定部３４５、及び報告処理部３４６を備える。便宜上、確認要求を実行したユーザのことをリクエストユーザと称する。

リクエスト車両特定部３４１は、広域通信部３１が受信した確認要求パケットに示されるユーザＩＤから、リクエストユーザに対応する車両ＩＤを特定する。つまり、リクエストユーザが利用している車両（以降、リクエスト車両）を特定する。

周辺車両データ抽出部３４２は、リクエスト車両の車両ＩＤに対応付けられている運転状況データに基づき、リクエストユーザが直近に実施したトリップ時においてリクエスト車両が走行した経路（以降、トリップ経路）を特定する。そして、そのトリップ経路を構成する各地点の位置情報及び通過時刻と、走行履歴ＤＢ３２に保存されている車両毎の走行履歴データに基づいて、前回トリップ時におけるリクエスト車両の近くを走行していた車両（以降、周辺車両）の運転状況データを抽出する。

ここで抽出される周辺車両の運転状況データは、自車両の近くを走行していたと見なすことができる条件を充足する運転状況データ（以降、周辺車両データ）である。具体的には、周辺車両データは、自車両が通過した地点を所定時間（例えば１秒）以内に通過した周辺車両の運転状況データのうち、自車両との距離が所定の近距離閾値（例えば５０ｍ）以内となっている運転状況データである。なお、近距離閾値は、リクエスト車両の走行速度などに応じて動的に決定されてもよい。その場合の近距離閾値は、リクエスト車両の走行速度が大きいほど大きい値に設定すればよい。

また、他の態様として近距離閾値は、リクエスト車両が走行している道路の種別に応じた値に動的に調整されてもよい。例えば、リクエスト車両が走行している道路の種別が高速道路である場合には、近距離閾値を相対的に大きい値（例えば２００ｍ）に設定する一方、走行道路が一般道路である場合には、走行道路が高速道路である場合よりも小さい値（例えば３０ｍ）に設定する。この周辺車両データ抽出部３４２の作動の詳細については、別途、周辺車両抽出処理として説明する。

危険遭遇シーン抽出部３４３は、周辺車両データ抽出部３４２によって抽出された周辺車両データに基づいて、周辺車両のドライバ（以降、周辺ドライバ）が危険を感じた場面（以降、危険遭遇シーン）があったか否かを判定する。そして、危険遭遇シーンが存在する場合には、その位置及び時刻を危険遭遇シーンとして抽出する。

危険遭遇シーンは、周辺ドライバが所定の危険反応行動を実施した位置、時刻によって表される。危険反応行動とは、例えば急な減速操作（いわゆる急ブレーキ）や、急な旋回操作（いわゆる急ハンドル）である。ここでは一例として、クラクションボタンの押下も危険反応行動に含めるものとする。危険反応行動の具体的な内容は適宜設計されれば良い。

危険反応行動の実施の有無は、周辺車両の走行履歴データから特定することができる。危険遭遇シーン抽出部３４３は、所定の閾値以上の減速度（換言すれば負の加速度）が発生している場面や、所定時間以内に所定の閾値以上の操舵角の変化が生じている場面、警笛装置（いわゆるクラクション）が作動した場面等、危険遭遇シーンとして抽出する。つまり、加速度や、操舵角、警笛装置の作動状態などが請求項に記載の判定用情報に相当する。

因果関係判定部３４４は、危険遭遇シーン抽出部３４３によって抽出された危険遭遇シーンにおいて、危険反応行動を実施した周辺車両（以降、危険遭遇車両）が危険反応行動を実施した原因が、リクエスト車両の挙動にあるのか否かを判断する。

例えば、危険遭遇車両とリクエスト車両との車間距離が十分に離れていたり、危険遭遇車両とリクエスト車両との間に他の車両が存在していたりする場合には、危険遭遇車両が危険反応行動を実施した原因はリクエスト車両ではないと判定する。また、危険遭遇車両が危険反応行動を実施した時点において、リクエスト車両が停車している場合にも、危険遭遇車両が危険反応行動を実施した原因はリクエスト車両ではないと判定する。

その他の場合には、本実施形態では一例として、危険遭遇車両が危険反応行動を実施した原因は、リクエスト車両の挙動にあると推定する。そして、危険遭遇車両が危険反応行動を実施した原因がリクエスト車両の挙動にあると推定した場合には、当該危険遭遇シーンを表す位置及び時刻において、リクエストユーザが危険運転を実施していたと判定する。

リクエスト車両の挙動に基づいて危険遭遇車両が危険反応行動を実施した危険遭遇シーンは、リクエストユーザが危険運転を実施していた場面（以降、危険運転シーン）に相当する。つまり、因果関係判定部３４４は、危険遭遇シーン抽出部３４３によって抽出された危険遭遇シーンの中から、危険運転シーンを抽出する役割を担う。危険遭遇シーン抽出部３４３と因果関係判定部３４４を組み合わせた部材が請求項に記載の危険運転シーン検出部に相当する。

なお、１つの実施態様として、危険運転シーンとして抽出する場面を、交差点や駐車場出入り口付近に限定する場合には、危険遭遇車両の進行方向とリクエスト車両の進行方向とがなす角度が所定の閾値（例えば４５度）以上となっていることを、危険遭遇車両がリクエスト車両の挙動に基づいて危険反応行動を実施したと推定する条件として採用すればよい。

認識状態判定部３４５は、因果関係判定部３４４によってリクエストユーザが危険運転を実施していた場面（つまり危険運転シーン）が存在すると判定された場合に、その場面から所定時間以内におけるリクエストユーザの生体情報と、後述するパラメータ記憶部３５に保存されているデータを用いて、リクエストユーザが当該危険運転の実施を認識しているか否かを判定する。この認識状態判定部３４５の詳細については別途、認識状態判定処理として後述する。

報告処理部３４６は、以上の処理の結果に基づいて前回のトリップ中に無自覚危険運転シーンがあったか否かを示すデータ（つまりトリップレポート）を生成し、広域通信部３１と協働して確認用端末２に送信する。無自覚危険運転シーンが存在する場合には、どのような運転操作が危険運転として抽出されたのかをリクエストユーザが認識するための情報（例えば、自車両と周辺車両の挙動を示す情報）がトリップレポートには含まれるものとする。

パラメータ記憶部３５は、不揮発性の記憶媒体を用いて実現されている。パラメータ記憶部３５には、認識状態判定部３４５が認識状態判定処理に用いるパラメータ（以降、判定用パラメータ）が格納されている。判定用パラメータは、リクエストユーザの生体情報の変化から、リクエストユーザが、危険運転を実施したことを認識しているか否かを判定するためのパラメータであって、危険運転を実施したことを自覚した時の生体情報の変化傾向を示すパラメータである。判定用パラメータの具体的な値は、種々の体格や性格の人物を想定した汎用的な設計値とすればよい。

より具体的には、本実施形態では、危険運転を実施したことを自覚した時（換言すればヒヤリハットした時）の心拍数の変化量のモデル値（以降、心拍変化モデル値）が、判定用パラメータとして格納されているものとする。心拍変化モデル値は、心拍数の変化から、ユーザが危険運転をしてしまったことを認識しているか否かを判定するための閾値として機能するパラメータである。

認識状態判定部３４５は、危険運転シーンが生じた直後又は所定時間経過後のユーザの心拍数が、平常時のユーザの心拍数よりも、心拍変化モデル値以上高い値になっている場合、ユーザが危険運転をしてしまったことを認識していると判定する。一方、ユーザの心拍数に、心拍変化モデル値以上の増加が生じなかった場合には、ユーザが危険運転をしたことを認識していないと判定する。心拍変化モデル値が請求項に記載の危険認識モデル値に相当する。

＜確認要求応答処理＞
次に、確認要求対応部３４が実施する確認要求応答処理について、図９に示すフローチャートを用いて説明する。この図９に示す確認要求応答処理は、確認要求パケットを受信した場合に開始されれば良い。

まずステップＳ３０１では、リクエスト車両特定部３４１が、確認要求パケットに示されるユーザＩＤ等に基づいてリクエストユーザ及びリクエスト車両を特定してステップＳ３０２に移る。ステップＳ３０２では周辺車両データ抽出部３４２が、走行履歴ＤＢ３２に保存されているリクエスト車両にとっての最新のトリップの経緯を示すトリップ経緯データ（以降、最新トリップデータ）に基づき、リクエスト車両の前回トリップ時の走行経路（すなわちトリップ経路）を特定してステップＳ３０３に移る。

ステップＳ３０３では周辺車両データ抽出部３４２が周辺車両データ抽出処理を実行する。この周辺車両データ抽出処理について、図１０に示すフローチャートを用いて説明する。図１０に示すフローチャートは、図９に示す確認要求応答処理のステップＳ３０３に移った時に開始される。

まずステップＳ４０１では、トリップ経路上に、トリップ開始地点からトリップ終了地点に向けて所定の間隔で演算用地点Ｐ（１），Ｐ（２），Ｐ（３），…，Ｐ（Ｎ）を設定してステップＳ４０２に移る。本実施形態では一例として、１秒毎の通過地点を演算用地点に設定する。つまり、出発してから１秒後、２秒後、３秒後、…、Ｎ秒後のそれぞれにおける地点を演算用地点に設定する。Ｎはトリップに要した秒数に応じて定まる自然数である。もちろん、他の態様として一定距離間隔（例えば１０ｍ間隔や、２０ｍ間隔等）で演算用地点を設定してもよい。

ステップＳ４０２では、以降の処理で使用する変数ｊに１を設定してステップＳ４０３に移る。ステップＳ４０３では、リクエスト車両のトリップ経緯データに基づいて、演算用地点Ｐ（ｊ）をリクエスト車両が通過した時刻Ｔ（ｊ）を特定してステップＳ４０４に移る。

ステップＳ４０４では、走行履歴ＤＢ３２を参照し、時刻Ｔ（ｊ）の前後一定時間（例えば１秒）以内に地点Ｐ（ｊ）を通過した車両を、地点Ｐ（ｊ）での周辺車両として抽出してステップＳ４０５に移る。ステップＳ４０５では、ステップＳ４０４で抽出した周辺車両の運転状況データのうち、生成時刻が時刻Ｔ（ｊ）の前後一定時間以内となっている運転状況データを周辺車両データとして抽出してステップＳ４０６に移る。

ステップＳ４０６では、変数ｊの値がＮよりも小さいか否かを判定する。変数ｊの値がＮよりも小さい場合にはステップＳ４０７に移る。ステップＳ４０７では変数ｊの値を１つ増加させて（つまりインクリメントして）ステップＳ４０３に戻る。

一方、ステップＳ４０６において、変数ｊの値がＮよりも小さくない場合には本フローを終了する。その場合、呼び出し元である確認要求応答処理のステップＳ３０４に移る。なお、変数ｊの値がＮよりも小さくない場合とは、全ての演算用地点についての周辺車両データの抽出が完了したことを意味する。

再び図９を参照し、確認要求応答処理のステップＳ３０４以降のステップについて説明する。ステップＳ３０４では、前述の周辺車両データ抽出処理の結果として、周辺車両データを抽出できたか否かを判定する。周辺車両データを抽出できなかった場合とは、トリップの全行程において、搭載車両がリクエスト車両の近くを走行していなかったことを意味する。

周辺車両データ抽出処理の結果として抽出された周辺車両データが存在しない場合には、ステップＳ３１２に移る。一方、周辺車両データが抽出されている場合にはステップＳ３０５に移る。

ステップＳ３０５では危険遭遇シーン抽出部３４３が、ステップＳ３０３で抽出された周辺車両データに基づいて危険遭遇シーンを抽出する処理を実行してステップＳ３０６に移る。ステップＳ３０６では、危険遭遇シーンが存在しているか否かを判定する。危険遭遇シーンが抽出されている場合にはステップＳ３０６が肯定判定されてステップＳ３０７に移る。一方、危険遭遇シーンが抽出されていない（換言すれば発生していない）場合には、ステップＳ３０６が否定判定されてステップＳ３１２に移る。

ステップＳ３０７では因果関係判定部３４４が、ステップＳ３０５で抽出された危険遭遇シーンにおいて、危険遭遇車両が危険反応行動を実施した原因が、リクエスト車両の挙動にあるのか否かを、それぞれの位置関係及びリクエスト車両の走行状態に基づいて判断する。危険遭遇車両が危険反応行動を実施した原因が、リクエスト車両の挙動にあると判定した場合にはステップＳ３０８が肯定判定されてステップＳ３０９に移る。その場合、危険遭遇シーンにおいてリクエストユーザが危険運転をしていたと判定する。つまり、その危険遭遇シーンを危険運転シーンと見なす。

なお、ステップＳ３０５において危険遭遇シーンが複数抽出されている場合には、それぞれの危険遭遇シーンに対してステップＳ３０７の判定処理を実行する。したがって、複数の危険遭遇シーンのそれぞれを対象とした判定処理を実施した結果、複数の危険遭遇シーンが危険運転シーンとして採用されることもある。

抽出された全ての危険遭遇シーンにおいて、危険遭遇車両が危険反応行動を実施した原因はリクエスト車両の挙動ではないと判定した場合には、ステップＳ３０８が否定判定されてステップＳ３１２に移る。

ステップＳ３０９では認識状態判定部３４５が、以上の処理によって抽出された危険運転シーンに対して認識状態判定処理を実施する。なお、以上の処理によって複数の危険運転シーンが抽出されている場合には、それぞれを処理の対象として認識状態判定処理を実施する。便宜上、処理の対象とする危険運転シーンを処理対象シーンと称する。

この認識状態判定処理については図１１に示すフローチャートを用いて説明する。図１１に示すフローチャートは、図９に示す確認要求応答処理のステップＳ３０９に移った時に開始される。

まず、ステップＳ５０１では、走行履歴ＤＢ３２に保存されているリクエストユーザの生体情報のうち、検出時刻が、処理対象シーンの発生時刻から所定時間（例えば４秒）以内となっている心拍数を抽出してステップＳ５０２に移る。

ステップＳ５０２では、最新トリップデータに示される心拍数に基づいて平常時心拍数を特定してステップＳ５０３に移る。平常時心拍数は、例えば危険運転シーンの一定時間前（例えば１０秒前）の心拍数とすればよい。また、トリップ中に収集された複数時点の心拍数の平均値や中央値を平常時心拍数として採用してもよい。

ステップＳ５０３では、パラメータ記憶部３５から判定用パラメータを読み出してステップＳ５０３に移る。ステップＳ５０４では、ステップＳ５０１で抽出した心拍数と、ステップＳ５０２で特定した平常時心拍数とから、心拍数の変動量（以降、心拍変動量）を算出する。具体的には、ステップＳ５０１で抽出した心拍数の最大値を、危険運転シーン後のリクエストユーザの心拍数として採用し、平常時心拍数との差（つまり、心拍変動量）を算出する。

そして、算出した心拍変動量が心拍変化モデル値以上となっている場合に、リクエストユーザは危険運転を実施したことを認識していると判定する。一方、心拍変動量が心拍変化モデル値未満となっている場合には、リクエストユーザが危険運転をしたことを認識していないと判定する。

ステップＳ５０４での処理が完了すると、本フローを終了する。また、危険運転シーンが複数抽出されており、未だ認識状態判定処理を実施していない危険運転シーンが残っている場合には、その危険運転シーンを処理対象シーンとした認識状態判定処理を実行する。全ての危険運転シーンに対する認識状態判定処理が完了した場合には、図９に示す確認要求応答処理のステップＳ３１０を実行する。

ステップＳ３１０では、ステップＳ３１０での処理結果として、リクエストユーザが認識せずに危険運転を実施していた場面（つまり無自覚危険運転シーン）が存在するか否かを判定する。無自覚危険運転シーンが存在する場合には、ステップＳ３１０が肯定判定されてステップＳ３１１に移る。一方、無自覚危険運転シーンが存在しない場合にはステップＳ３１０が否定判定されてステップＳ３１２に移る。

ステップＳ３１１では、無自覚危険運転シーンが存在することを示すトリップレポートを送信して本フローを終了する。具体的には、無自覚危険運転シーンとして抽出された位置及び時刻において、リクエスト車両及び危険遭遇車両の挙動を示す情報を含むトリップレポートを送信する。

ステップＳ３１２では、周辺ドライバに危険を感じさせる運転操作は検出されなかった旨を示すトリップレポート生成して本フローを終了する。

＜実施形態のまとめ＞
以上の構成では、センタ３の保存処理部３３は、各搭載車両の挙動等を示す運転状況データを走行履歴ＤＢ３２に蓄積していく。そして、確認要求対応部３４は、ユーザからの問い合わせに基づいて、確認要求応答処理を実施する。

具体的には、リクエスト車両の近くを走行した他の車両（つまり周辺車両）の挙動と、リクエスト車両の挙動とから、リクエストユーザが危険運転を実施した場面（つまり危険運転シーン）を抽出する。

次に、危険運転シーン発生直後におけるリクエストユーザの生体情報と、平常時の生体情報を比較することによって、リクエストユーザ自身が、危険運転を実施したことを自覚しているか否かを判定する。その結果として、リクエストユーザが危険運転を実施したことを自覚していない場面（つまり無自覚危険運転シーン）が抽出される。

そして、無自覚危険運転シーンが存在する場合には、その具体的な内容をリクエストユーザが認識するための情報を含むトリップレポートを確認用端末２に送信する。したがって、ユーザは確認用端末２を操作することによって、自覚できていない危険運転シーンを知ることができる。

また、以上の構成によれば、ユーザが危険運転をしてしまったと自覚していると推定される危険運転シーンについては、ディスプレイ２２に表示されない。つまり、ユーザに提示されない。一般的に、ユーザが自覚している危険運転についての情報は、自覚できていない危険運転の情報よりも、ユーザにとっての有用性は低い。

したがって、以上の構成によれば、ユーザにとって相対的に有用性が高い情報を優先的に提示することができる。なお、他の態様として、ユーザが自覚している危険運転シーンの情報についても提示してもよい。

また、特許文献１に開示の構成では、ユーザが過去に走行したことがある経路でしか、ユーザの危険運転を検出できない。一方、以上の構成によれば、危険運転シーンは周辺車両の挙動に基づいて抽出される。そのため、ユーザが初めて走行する経路においても、ユーザが危険運転を実施したか否かを判定することができる。

以上、本発明の実施形態を説明したが、本発明は上述の実施形態に限定されるものではなく、以降で述べる種々の変形例も本発明の技術的範囲に含まれ、さらに、下記以外にも要旨を逸脱しない範囲内で種々変更して実施することができる。例えば、下記に記載の変形例を複数組みあせわせて実施することもできる。

なお、前述の実施形態で述べた部材と同一の機能を有する部材については、同一の符号を付し、その説明を省略する。また、構成の一部のみに言及している場合、他の部分については先に説明した実施形態の構成を適用することができる。

［変形例１］
上述した実施形態では加速度や操舵角といった車両挙動から、危険遭遇シーンを検出する態様を開示したが、これに限らない。運転状況データとして、ユーザの発話内容や声調、表情を示すデータをセンタ３に送信する場合には、周辺ドライバの発話内容や声調、表情から、危険遭遇シーンを検出してもよい。

例えば、周辺ドライバが「危ない」「うわっ」といった、ヒヤリハットに伴うリアクションとして予め定義された発言をしている場合には、その場面を危険遭遇シーンとして抽出する。また、周辺ドライバが、例えば目を見開いたりするなどの、驚いた表情をしている場合に、その場面を危険遭遇シーンとして抽出してもよい。

［変形例２］
車両用ユニット１が、図１２に示すように、車室外の所定領域（例えば車両前方）を撮影するように車両に設置された車室外カメラ１０５と接続されている場合には、車室外カメラ１０５の撮影画像を運転状況データに含めても良い。図１２にＦ４で示す機能ブロックは、車室外カメラ１０５の撮影画像データを取得する機能ブロックである。

そのような態様によれば、リクエスト車両の運転状況データに含まれる画像データを解析することで、リクエスト車両の挙動に対して危険を感じている歩行者や自転車乗員等を検出することができる。つまり、撮像画像から危険遭遇シーンを抽出することができる。

また、因果関係判定部３４４は、危険遭遇車両の運転状況データに含まれる画像データを解析することによって、危険遭遇車両が危険反応行動を実施した原因が、リクエスト車両の挙動にあるか否かも判別できる。例えば危険遭遇車両の撮像データを解析した結果、リクエスト車両以外の車両（つまり第３の車両）の挙動に起因して、危険遭遇車両のドライバが急ブレーキを実施していると判定できた場合には、危険反応行動の実施要因はリクエスト車両では無いと判定できる。

［変形例３］
車両用ユニット１は、図１３に示すように機能ブロックとして危険認識反応学習部Ｆ５を備えていても良い。危険認識反応学習部Ｆ５は、判定用パラメータの値を、ユーザの特性に応じたユーザ固有の値へと調整するための機能ブロックである。危険認識反応学習部Ｆ５はより細かい機能ブロックとして、危険認識検出部Ｆ５１を備える。

危険認識検出部Ｆ５１は、急ブレーキや急ハンドル、ユーザの発話内容、声調、表情から、ユーザ自身が危険を感じた状況を検出する。また、その余事象として、ユーザが危険を感じていない状況と検出する。つまり、ユーザが危険を感じている状況であるか否かを判定する。

危険認識反応学習部Ｆ５は、危険認識検出部Ｆ５１によってユーザは危険を感じていないと判定されている状況において取得した生体情報を、平常時サンプルデータとして保存する。また、危険認識検出部Ｆ５１によってユーザが危険を感じていると判定されている状況において取得した生体情報を、危険認識時サンプルデータとして保存する。

そして、危険認識サンプルデータの代表値と、平常時サンプルデータの代表値との差分を、危険認識時傾向データとして、センタ３に送信する。各種の代表値は、平均値であってもよいし、中央値であってもよい。

また、本変形例３におけるセンタ３は、車両用ユニット１から送信されてくる危険認識時傾向データに基づいて、パラメータ記憶部３５に保存されている判定用パラメータを、ユーザ毎の特性を反映したパラメータへと調整するパラメータ調整部３６を備える。さらに、パラメータ記憶部３５にはユーザ毎の判定用パラメータが格納されている。なお、図１３では保存処理部３３及び確認要求対応部３４の図示は省略している。

例えばパラメータ調整部３６は、或るユーザについての危険認識時傾向データを取得した場合には、そのユーザについての現在の判定用パラメータの値と、新たに取得した危険認識時傾向データから定まる値とを所定の比率で足し合わせた値を、新たな判定用パラメータの値として採用すればよい。

このような構成によれば、判定用パラメータの値が、ユーザ特性に応じた値となるため、危険運転の実施に対する認識の有無の判定精度を高めることができる。なお、危険認識反応学習部Ｆ５は、センタ３が備えていても良い。

［変形例４］
上述した実施形態では、所定のアップロード間隔で運転状況報告データを送信する態様を開示したが、これに限らない。トリップ終了時にトリップ中の運転状況データをまとめてセンタ３に送信してもよい。

［変形例５］
上述した実施形態では、トリップ終了後に無自覚危険運転シーンの発生についてユーザに通知する態様を開示したが、これに限らない。トリップの途中において逐次通知されても良い。

［変形例６］
請求項に記載の他移動体装置は、車両で用いられる装置に限らない。歩行者が携帯するスマートフォン等の携帯端末を他移動体装置として採用してもよい。その場合、他移動体装置としての携帯端末は、自端末に作用する加速度、及び、位置情報を挙動データとしてセンタ３に逐次送信するものとする。なお、他移動体装置としての携帯端末は、ユーザの脈拍数などの生体情報を取得する機能を備えていることが好ましい。例えば携帯端末は、脈波センサを備える携帯端末であることが好ましい。脈波センサを備える携帯端末としては、例えば腕時計型の携帯端末などがある。

センタ３の保存処理部３３は、携帯端末から送信されてくる挙動データについても、運転状況データと同様に、携帯端末の端末ＩＤやユーザＩＤと対応付けて走行履歴ＤＢ３２に保存する。そして、危険遭遇シーン抽出部３４３は、携帯端末に作用している加速度の変化からも危険遭遇シーンを抽出する。

例えば、リクエスト車両の近くに存在した携帯端末に、所定の閾値以上の加速度が作用していた場合には、その場面を危険遭遇シーンとして抽出する。ここで採用される閾値は、携帯端末のユーザが、急に立ち止まったり、急いで移動したりなどの、リクエスト車両との接触を回避するための行動を実施したことを検出するための閾値である。

脈波センサを備える携帯端末を他移動体装置として適用している場合には、危険遭遇シーンを抽出するための挙動データに脈拍数を追加することで抽出精度を向上できる。例えば歩行者が立ち止まって安全確認をしているときに車両が近くを通過したような場合等といった、加速度だけでは危険遭遇シーンを抽出できない場面についても、危険遭遇シーンとして抽出できる。

［変形例７］
他移動体として、様々な種別の移動体を想定する場合には、危険遭遇シーンを抽出するための加速度に対する閾値（以降、加速度用閾値）は、移動体種別に応じて使い分けられることが好ましい。これは、例えば車両と歩行者とでは、危険反応行動として観測されうる加速度が大きく異なるためである。具体的には、他移動体が車両である場合に採用する加速度用閾値の絶対値は、他移動体が歩行者である場合に採用する加速度用閾値よりも大きい値とする。

このような態様によれば、リクエスト車両の周辺に存在する移動体の種別に応じた加速度用閾値を用いて、危険遭遇シーンを抽出することができる。なお、この変形例７の前提として、携帯端末や車両用ユニット１などの、各種移動体で使用される装置がセンタ３に送信するデータには、送信元としての移動体の種別を示す情報（以降、移動体種別情報）が含まれるように構成されているものとする。

移動体種別情報は、平均的な移動速度から自動的に決定されても良いし、ユーザが手動で登録してもよい。移動体の種別としては、自動車、歩行者、自転車などが想定される。

［変形例８］
危険を感じていない場合でもユーザの癖により、上述の加速度用閾値を越えるブレーキやハンドル操作をしてしまう場合が有り得る。したがって、心拍数や血圧などの生体情報を併用して危険遭遇シーンを抽出してもよい。

例えば、加速度閾値を越えた場合に心拍数や血圧が上昇していない場合は、危険遭遇シーンとして抽出しない。そのような態様によれば、危険遭遇シーンの抽出精度を向上させることができる。

［変形例９］
以上では、運転支援システム１０００として、センタ３を備える構成を開示したが、これに限らない。センタ３が備える機能は、車両に搭載されていても良い。その場合、車両用ユニット１同士は、車車間通信によって直接的に運転状況データを共有すればよい。また、歩行者等が備える携帯端末とは路側機を介して通信すればよい。

［変形例１０］
以上では、ユーザからの確認要求に基づき、直近のトリップのみを対象として無自覚危険運転シーンがあったか否かを判定しているが、過去の複数のトリップを対象にしてもよい。すでにユーザに通知した危険運転シーンの発生は、通知しないようにしてもよい。

１０００ 運転支援システム、１・１ａ・１ｂ・１ｃ 車両用ユニット、Ｆ１ 車両情報取得部、Ｆ２ 生体情報取得部、Ｆ３ 送信処理部、２ 確認用端末、２１ 操作部、２２ ディスプレイ、２３ 広域通信部、２４ 確認処理部、３ センタ、３１ 広域通信部、３２ 走行履歴データベース、３３ 保存処理部、３４ 確認要求対応部、３４１ リクエスト車両特定部、３４２ 周辺車両データ抽出部、３４３ 危険遭遇シーン抽出部、３４４ 因果関係判定部、３４５ 認識状態判定部、３４６ 報告処理部、３５ パラメータ記憶部、３６ パラメータ調整部

Claims (11)

1. 車両で使用される装置であって、前記車両に搭載された生体情報センサから、前記車両のドライバとしての第１ユーザの生体情報を逐次取得する生体情報取得部（Ｆ２）と、前記車両に搭載された車両情報センサから、前記車両の走行状態を示す情報であって、少なくとも前記車両の位置情報を含む車両情報を逐次取得する車両情報取得部（Ｆ１）と、を備える車両用装置（１ａ）と、
   前記車両とは異なる移動体で使用される装置である他移動体装置から、前記他移動体装置を使用している人物である第２ユーザが危険を感じたか否かを判定するための指標として機能する判定用情報と、前記他移動体装置の位置情報とを、他移動体情報として逐次取得する他移動体情報取得部（３１）と、
   前記生体情報取得部が逐次取得する前記生体情報と前記車両情報取得部が逐次取得する前記車両情報とを、時刻情報と対応付けて記憶部（３２）に保存するとともに、前記他移動体情報取得部が逐次取得する前記他移動体情報を、時刻情報と対応付けて前記記憶部に保存する保存処理部（３３）と、
   前記記憶部に保存されている前記他移動体情報と前記車両情報に基づいて、前記第２ユーザが、前記車両の挙動に対して危険を感じたと推定される場面である危険運転シーンを検出する危険運転シーン検出部（３４３，３４４）と、
   前記危険運転シーン検出部によって検出された前記危険運転シーンにおいて、前記第１ユーザが危険運転を実施したことを自覚しているか否かを、前記記憶部に保存されている前記生体情報から判定する認識状態判定部（３４５）と、
   前記認識状態判定部が前記第１ユーザは前記危険運転シーンにおいて前記危険運転を実施したことを自覚していないと判定した場合には、前記危険運転シーンについての情報を前記第１ユーザに提示する提示処理部（２４）とを備えることを特徴とする運転支援システム。
2. 請求項１において、
   前記提示処理部は、前記認識状態判定部が前記第１ユーザは前記危険運転を実施したことを自覚していると判定した前記危険運転シーンについての情報は、前記第１ユーザに提示しないことを特徴とする運転支援システム。
3. 請求項１又は２において、
   前記危険運転シーン検出部は、
   前記記憶部に保存されている前記判定用情報に基づいて前記第２ユーザが危険を感じた場面である危険遭遇シーンを検出するとともに、
   前記危険遭遇シーンにおける前記他移動体装置の位置情報と前記車両の位置情報から定まる前記他移動体装置と前記車両の位置関係、及び、前記危険遭遇シーンにおける前記車両の挙動の、少なくとも何れか一方に基づいて、前記第２ユーザが前記車両の挙動に対して危険を感じたのか否かを判定し、
   前記第２ユーザが前記車両の挙動に対して危険を感じたと判定した場合に、前記危険遭遇シーンを前記危険運転シーンとして検出することを特徴とする運転支援システム。
4. 請求項３において、
   前記危険運転シーン検出部は、前記危険遭遇シーンにおける前記他移動体装置と前記車両とが所定の距離以上離れている場合、又は、前記危険遭遇シーンにおいて前記車両が停車している場合、又は、前記他移動体装置に対応する前記移動体と前記車両との間に第３の移動体が存在する場合には、前記危険遭遇シーンにおいて前記第２ユーザは前記車両の挙動に対して危険を感じたのではないと判定することを特徴とする運転支援システム。
5. 請求項３又は４において、
   前記危険運転シーン検出部は、前記危険遭遇シーンにおける前記他移動体装置の近くと見なすことができる所定の距離以内に、前記第２ユーザに危険を感じさせる挙動をしている他車両が存在している場合には、前記危険遭遇シーンにおいて前記第２ユーザは前記車両の挙動に対して危険を感じたのではないと判定することを特徴とする運転支援システム。
6. 請求項３から５の何れか１項において、
   前記他移動体装置は、前記他移動体装置に作用する加速度を検出する加速度センサを備え、
   前記他移動体情報取得部は、前記判定用情報として、前記他移動体装置に作用している加速度を逐次取得し、
   前記危険運転シーン検出部は、前記他移動体装置が前記車両から所定距離以内に位置している状況において、前記他移動体装置に作用している加速度が、所定の加速度用閾値以上の値となっていることに基づいて、前記危険遭遇シーンを検出することを特徴とする運転支援システム。
7. 請求項６において、
   前記他移動体情報は、前記他移動体装置が使用されている移動体の種別を示す移動体種別情報を含み、
   前記加速度用閾値として、前記移動体の種別に応じて複数の値が予め設定されており、
   前記危険運転シーン検出部は、前記移動体種別情報に応じた前記加速度用閾値を用いて、前記危険遭遇シーンを検出することを特徴とする運転支援システム。
8. 請求項１から７の何れか１項において、
   前記他移動体装置として、前記第１ユーザが運転する前記車両である自車両とは別の車両である他車両で使用される他車両用装置（１ｂ、１ｃ）を備え、
   前記第２ユーザは前記他車両のドライバであって、
   前記他移動体情報取得部は、前記他車両用装置からは前記判定用情報として、前記他車両に作用する加速度に加え、前記他車両に付与されている操舵角、前記他車両が備える警笛装置の作動状態、前記第２ユーザの生体情報の少なくとも何れか１つを取得することを特徴とする運転支援システム。
9. 請求項１から８の何れか１項において、
   前記生体情報は、前記第１ユーザの心臓の一定時間当りの拍動数を示す情報であり、
   前記認識状態判定部は、前記危険運転シーンにおける前記生体情報としての前記拍動数と、前記危険運転シーンとして検出されていない場面における前記拍動数とを比較して、
   前記拍動数に所定の危険認識モデル値以上の変化が生じている場合に、前記第１ユーザは当該危険運転シーンにおいて前記危険運転を実施したことを自覚していると判定する一方、前記拍動数に前記危険認識モデル値以上の変化が生じていない場合には、前記第１ユーザは当該危険運転シーンにおいて前記危険運転を実施したことを自覚していないと判定することを特徴とする運転支援システム。
10. 請求項９において、
    前記第１ユーザが危険を感じたときの前記拍動数と、平常時の前記拍動数との差に基づいて、前記危険認識モデル値を調整するパラメータ調整部（３６）を備えることを特徴とする運転支援システム。
11. 請求項１から１０の何れか１項において、
    前記車両用装置は及び前記他移動体装置のそれぞれは広域通信網に無線接続可能に構成されており、
    前記車両用装置及び前記他移動体装置のそれぞれと広域通信網を介して通信を実施するセンタ（３）を備え、
    前記センタが、前記他移動体情報取得部、前記記憶部、前記保存処理部、前記危険運転シーン検出部、前記認識状態判定部を備えることを特徴とする運転支援システム。

Images